21–30 of 35 posts
Forgive my bluntness, but why is ACM publishing a couple of academics' personal choice of lightweight coding standard, and why are so many Hackers upvoting it? Is there some hidden depth here that I'm missing, or some underlying research that shows these preferences are objectively better than some of the alternatives?
A standard argument against aligning multiple similar lines of declarations as a table is that you constantly need to re-align when you add/remove declarations. One implication is that source diffs become larger than necessary as they will now include lines that haven't actually changed content-wise, only layout-wise.
Code is read many more times than it's written. Re-aligning isn't really time consuming.
I'm quite disappointed the article doesn't mention that.
A standard argument against aligning multiple similar lines of declarations as a table is that you constantly need to re-align when you add/remove declarations. One implication is that source diffs become larger than necessary as they will now include lines that haven't actually changed content-wise, only layout-wise.
A standard argument against aligning multiple similar lines of declarations as a table is that you constantly need to re-align when you add/remove declarations. One implication is that source diffs become larger than necessary as they will now include lines that haven't actually changed content-wise, only layout-wise.
In emacs, one can take out the drudgery of manually aligning and realigning your variables in tabular fashion using the align commands[1]. In certain revision control systems, one doesn't keep differences, but whole objects, so the point is moot there unless you have some serious bandwidth concerns. [1] http://www.emacswiki.org/emacs/AlignCommands
This reminds me of a blog post I read several years ago where the author connected the concision of code to the experience the author of the code had. More experienced coders needed less comments and could read higher-density code with less mental effort. Wish I could find that blog post again, I've thought of it from time to time over the years. edit: speeling. edit2: Yegge strikes again. Wow. Amazingly influential…
This is interesting, and not something I'd consciously thought about before, but quite often I will go back after I've finished something and add some white space and (sometimes quite thorough) comments to the code I've written. I especially do this with open source code that I plan to release. My reason for doing this is that I want to make it clear to whoever ends up maintaining the code after I've left the project…
If you write a piece of code and think you need to comment it because it won't be clear for the next guy. It is good at best.
Furthermore, comments rarely help. They are written while you are in complete comprehension of the program or that part of it. The next person (assuming the comment is something they are using to figure it out) won't be.
That said, if you can do nothing to improve the quality because of time, lack of interest or necessary complexity. At least, make your best effort to comment what it does. Appreciating the fact that this is a minimal quality improvement action. Sometimes it is just a piece of code that has to be optimized, explain why so the next guy doesn't refactor/re-write it.
Earlier quoted context omitted.
In emacs, one can take out the drudgery of manually aligning and realigning your variables in tabular fashion using the align commands[1]. In certain revision control systems, one doesn't keep differences, but whole objects, so the point is moot there unless you have some serious bandwidth concerns. [1] http://www.emacswiki.org/emacs/AlignCommands
It's not only about bandwidth concerns, it's more about making commit diffs readable. If you have ten lines of tabular assignments and you changed the sixth, but that made you realign everything, then you'll see 10 green lines + 10 pink lines in your commit diff, even though you should only see two lines in total.