4 ms·
I take issue with the notion that comments are "noise".
by knieveltech 9y ago
I take issue with the notion that comments are "noise".
- eradicatethots 9y agoI don’t
- nomel 9y agoI've never once come back to my own code, say, three months later, and wished I had less comments.
- kruczek 9y agoI did, although I admit it was only for awful projects, where people used to comment out code instead of deleting it... hundreds of lines of commented out code and occasionally one or two lines uncommented in the middle of that. Not fun to maintain code in such state.
- icc97 9y agoCommented out code, is not a comment about the code. It's just someone not clearing their trash.
- knieveltech 9y agoI'm glad we don't work together, I'd surely get you fired. ;)
- xelxebar 9y agoI take a philosophy that "executable comments" are better than "static comments". So instead of writing a comment to explain some gnarly bit of logic, I'll try to do the reverse of inlining and break pieces into little, suitably-named functions. The vast majority of my comments are either javadoc-style function protocols or high-level discussion on subsystem purpose and architecture. Leaning on this commenting style, I find that looking at past code of mine is much easier to re-grok than having lots of explanatory comments everywhere.
- eradicatethots 9y agoDon't you think actually breaking them into functions is excessive? I think any programmer worth their salt, with the aid of sublime text style search, can understand any codebase.
- oldandtired 9y agoInteresting that you write "any programmer worth their salt" has to have the aid of "sublime text style search". Having had to maintain and rebuild other programmers' monstrosities of monolithic functions, I appreciate short code routines and relevant comments, especially those that detail why the code is written that way. I then don't have to spend enormous amounts of time trying to understand the thought processes that went into making that code. If you are worth your "salt", you will write clear code and when it needs to be "tricky", you detail "the why" that you needed to do this. Different people have different standards as to what is clear code and often, this is dependent on the idiomatic usage within the language in question. A real simple example for you to ponder: if a < b & b < c & c < d & d <= e then { do something} compare with if a < b < c < d <= e then { do something } In this particular case, the first is how many programmers would write the condition, whereas the second is idiomatically more correct. The second is also, in this instance directly self documenting. Of course, how you will do this in your favourite language will be different.
- deleted 9y ago[deleted]
- knieveltech 9y agoEven if your assertion is true (and I've seen some codebases that would certainly put it to the test) on what grounds is spending an indeterminate (likely nontrivial) amount of time groveling a codebase with search preferable to having the code at least somewhat organized and documented in the first place?
- xelxebar 9y agoNot at all. All else being equal, if I can write code that is understandable to more people with less effort, that seems like an obvious win. I couldn't care less about sizing up your programming saltiness.