Hacker News new | past | comments | ask | show | jobs | submit login

If someone is hired to work on your code base, presumably they know the language. They know ternarys work...

If they don't then they need to learn.

You can't say don't use specific language features because some devs can't be bothered to learn them.




I know ternary operators very well but I still have to think twice when I see them nested

“You can't say don't use specific language features because some devs can't be bothered to learn them.”

Would you say the same about C++? In my view it’s a good practice to use only a subset of a language consistently and not use all features. I have seen JavaScript code where I had to do research for half an hour before I could figure out what it really meant.


> I have seen JavaScript code where I had to do research for half an hour before I could figure out what it really meant.

My view on this has flip flopped several times during my career. I think every spec has some dusty corners that most people don’t know about, but when a situation calls for it knowing about some obscure features can make your code far more readable. Sometimes it’s better in the long run to train your team about a feature they might not know about rather than code for the lowest common denominator. This thread is a great example - I spent my first decade of programming scared of chained terneries. One day I spent a couple of hours goofing around with them, playing with different ways I could write my code and internalising their semantics. Now they seem fine. I wish I’d taken the time to do that years ago. Ten years being afraid saved me 2 hours of time learning.

One of the best programmers I worked with reads the specs of tools he uses for fun. He says specs seem daunting but you can read them in far less time than you think and there’s always some fascinating stuff in there. My HTML knowledge got way better working with him - and its funny seeing how many tools struggle with correct HTML because the authors didn’t bother actually learning it.

Some more examples: html void elements, html/body tag auto insertion, JS tagged break/continue, C/JS/etc’s comma operator.


I've been taking the approach of writing code at the highest level of trickery/abstraction that is well-supported by my automated refactoring, debugging, and static analysis tools. This usually means keeping code quite simple. I can then play around with the code much easier if I need to make any changes, and I don't have to focus on the details much because they are quite explicit.

If something is so detailed that it gets too long to be quickly readable I extract it into a separate properly-named function.

I'm definitely drawn to using all the tricks of a language and I feel like it would be a great way to show off how smart I am, but I'm not sure its worth it for sacrificing comprehension and ease of adding stuff in later. Maybe if everyone that will ever work or use that code is top-notch, that would be a dream.


>If someone is hired to work on your code base, presumably they know the language. They know ternarys work...

It's not whether some constructs are parts of the language (languages can have any crap in), it's whether some constructs are bad, confusing, and should be avoided (whether you know what they do or not).


If people are confused by a ternary statement I don't want them editing code I have to maintain.


If someone thinks people can't or shouldn't be confused by a ternary statement, then I don't want them editing code I have to maintain either...


how many branches/how much depth in a ternary statement would you consider to be too many/too much?

Is there never going to be any level of depth in a ternary statement which you will think is perhaps too great, and want to switch to some more verbose syntax?


A lisper would say that there is absolutely no limit, and that in fact all programs should be structured like that.


To be clear, a lisper would not solve the problem by switching to a more verbose syntax, but that doesn't mean no depth is too deep. Breaking a big, deeply-nested function up into smaller ones is a perfectly lispy thing to do.



And that's why lispers are at most 1% of the total number of programmers out there, 50+ years after the language was invented.

You could say that most programmers are crap, but those crap programmers seem to make the world work, so they must be doing something right :-)


> You could say that most programmers are crap

Because they are

> but those crap programmers seem to make the world work

For certains value of "work". Most software is crap too and it's getting worse not better.


Yet it makes people's live better day by day... I feel that as insiders we don't really realize that software works quite well compared to many every day things.


The problem is not knowing how ternaries work, it's about how explicit is that line of code.


Exactly; to use the phrasing used in the presentation, it's about how difficult it is to decode the statements. I'm not a C guy; a regular ternary is fine, as long as it's simple enough. A nested ternary? That gives me all kinds of red flags because I have to lean in and frown and go over it a few times to decode it.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: