The Art and Science of Great Code
queue.acm.org
The Art and Science of Great Code
1–10 of 35 posts
Re: The Art and Science of Great Code
#2This 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 guy for me.
Re: The Art and Science of Great Code
#3Failure to use proper spelling in code is a cultural disease. Misspellings in English are looked down upon so why do we put up with it in code? Well I don't.
The authors code examples go back and forth between spelled correctly and not spelled correctly so I'm not quite sure what hes advocating. Figure 13 is especially hilarious.
pload: I have no idea what 'p' is
qload: I have no idea what 'q' is
numBuses: should have been busCount probably
numTransLines: what is 'trans' ?
systemName: ah a good one!
gens: should have been generators but even in that case its basically useless. I already know its a vector of Generators, what is its higher level function?
transLines and buses: same as 'gens', just a name of the type.
Re: The Art and Science of Great Code
#4A 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.
Re: The Art and Science of Great Code
#5This 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…
As a corollary, I can tell a code review session has reached its end when we start debating coding style, which I find happens about 2 minutes after we agree to talk about coding style at all. I've never found the intricacies of variable naming helpful, though I've participating in a number of discussions on the subject.
Code style guidelines are just that: guidelines. Being able to work in a group with a broad range of coders (from inexperienced to hyper-genius) is a highly useful skill for a coder.
Being able to communicate about the project to management, customers, and online is an even greater skill.
Re: The Art and Science of Great Code
#6This 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…
Re: The Art and Science of Great Code
#7Forgive 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?
Re: The Art and Science of Great Code
#8Failure to use proper spelling in code is a cultural disease. Misspellings in English are looked down upon so why do we put up with it in code? Well I don't. The authors code examples go back and forth between spelled correctly and not spelled correctly so I'm not quite sure what hes advocating. Figure 13 is especially hilarious. pload: I have no idea what 'p' is qload: I have no idea what 'q' is numBuses: should hav…
I couldn't agree more.
Take any book you haven't read that is openly available online. Remove all vowels in worlds longer than 4 characters. Replace commonly used words (like 'the') with your favorite abbreviation (like 'T'). Truncate extra long words (9+ characters). Then try to read it. Horrible, isn't it?
Reading abbreviated (or worse, one-letter) variable names is like translating from a made-up language.
Re: The Art and Science of Great Code
#9This 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. I have no idea what their skill level might be and getting up to speed on someone else's code can be tedious. Apparently this also makes me look like a less-skilled developer?
Re: The Art and Science of Great Code
#10Forgive 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?
Sometimes it's useful to have a new way to think about the same boring old problem. Personally, I like this set of guidelines because it focuses on things that make code more readable and pleasant to work with instead of getting bogged down in minutiae like where braces go or whether or how I have to import things.