Right on, gents. But now that you bring up these points, I hope one more comment is OK.
Talvieno wrote:I prefer to go with "what works" rather than "what's flashy" - after all, nobody's going to see your code in the finished product. The outcome is what matters.
This has the right spirit in the sense that when you're writing code for a customer, they care about functionality: Does it do what it has to do? Is how to use it clear?
That agreed to, I actually emphasize code clarity in a regular production environment to promote good code maintenance. In that setting, it is wrong to write code that other people -- including normal human beings who know how to program -- can't understand. This clarity is needed for multiple reasons: peer review, backup support in case the primary developer gets hit by a bus, and long-term maintenance and enhancement.
I consider this a customer service requirement.
Scytale wrote:I'm glad you guys say this, top answers on stackexchange usually drive me nuts because they're 'clever' and 'obviously the best way'
I cannot stop my eyes from rolling at how many useful answers on StackExchange are followed by "that is obviously incorrect; do you even know how to code?"-style responses.
It has to be admitted that, sometimes, they're right. I've seen a lot of initial suggestions that weren't quite
right, even if they get the person who asked the question going in the right direction (which is the most important thing). I just wish the clarification responses didn't come laden with so much Attitude.
I've also seen some great responses from people who've actually read the applicable standards documents, who deeply understand them, and who are good at explaining how to apply them. Interestingly, when these respondents provide a correction, they're usually pretty decent about it, or at least not insulting.
Scytale wrote:i should also add that the reason the aforementioned code is incomprehensible to me is because it is legitimately trying to do some very tricky data handling in what has to be an absolutely memory-efficient way, and it kind of ends up being necessarily labyrinthine anyway
Understood. This sort of thing does exist, and it's why I was careful to qualify my previous comment by referring to "the vast majority of programs."
There are cases in which the prioritization changes so that clarity is not so clearly the most important thing:
- one-time use to solve an immediate, specialized problem
- memory constraints (embedded software, satellites & robotic explorers)
- games whose core code will only ever be seen by a single gifted programmer
I do consider these the exceptions, though.
Scytale wrote:That being said the comments are still the annoying kind of "declare the GAB object" right above a statement clearly declaring a GAB object, and no one ever says what a GAB object actually is but I know it's bloody important
Commenting style always seems to have a lot to do with the personality of the developer. Unless you're willing and able to stand over their shoulder while they code, at some point you have to rely on them to follow a coding standard (whether they like it or not... and it's almost always "not").
At that point, either they naturally "get it" -- that the meaning of the comment needs to be one level up from the text of the code itself -- or they never will, and it will be an ongoing fight that ends only when one of you retires or gets a different job. (Of course there also usually needs to be explanatory text more than one level above the code, but that should probably be handled in requirements and design docs.)
Finally, I want to be sure I'm not dissing Josh by my comments about "elegance." Knuth's admonition that "premature optimization is the root of all evil" is a good warning about the value of one's time. I mention it because I think a quest for ever-increasing elegance can have the same effect. The value of optimizing code, when it's running well enough, before the whole program is basically feature-complete is not zero, but it's pretty close because at any time, that code might go away completely due to an algorithm change. At that point all the sweat that went into making those lines of code performant or elegant was for nearly nothing. "Nearly" because all coding teaches better coding... but the real point was to produce working software, and you're not doing that if you're spending hours or days shaving off milliseconds on non-core loops or working out the simplest conceivable common format for similar functions.
All that said, Josh's needs for LT are a little different than those of most programmers. For him, elegance seems to have more value because it lets him see a large amount of code in a normalized format. By pushing the "meaning" of code into how that code is structured, he can understand more code. That actually is useful because he's the only developer.
So when I'm banging on about how seeking elegance is dangerous, I'm talking about coding in a typical multi-developer business setting.
Josh and LT are their own thing.