Re:Clear is better than clever [pdf]
by Random_Person on Monday May 06, 2019 @09:33AM
(#19839226)
Writing for yourself is a fallacy. We can all read our own code. Write for the next guy who has to look at it and figure out what is going on.
> We can all read our own code
Six-months-ago-myself thought so as well. Turns out six-months-ago-myself is a goddamn moron.
It's also a fallacy that a ternary operator is some impossible to understand concept that will make the code totally unreadable for everyone but you. C programmers should be fine with the use of ternary operators for something like the example shown here.
Who should you be writing for? Everyone is different. What's clearer for one person might be harder to read for someone else.
Re:Clear is better than clever [pdf]
by optimuspaul on Monday May 06, 2019 @02:43PM
(#19842466)
totally agree, but life is full of compromise. I like to write code so that someone new to field could without too much effort follow what's going on but also so that someone better than I isn't so bored that they miss obvious things in the code (which does happen).
It's a balancing act which I have found to be one of the more fulfilling aspects of my work. Having people of different skill levels review my code has made this much easier.
One thing that I do a lot though is format code in a way that certain patterns appear for those of us that like to skim code. This generally means avoiding ternary operations except for very simple things where that pattern is easily recognized. But when to do that depends on the team(s) involved.
When they are, you basically get something that looks visually like a decision tree. This can read really nicely in situations where declarative style code fits better - for example embedding nested ternarys in JSX is quite a popular pattern for this reason.
The caveat is, you have to be 'used to' reading the ? and : symbols and instantly mapping them to if/else, but I certainly don't think getting used to this in a short time frame is beyond expectation for someone who's not already, i.e. new team members etc.