Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Art and Science of Great Code

queue.acm.org

Post reply on HN
Print view View original

11–20 of 35 posts

Re: The Art and Science of Great Code

#11

Post by wcarss »

gambler wrote: post #8
jon6 wrote: post #3

Failure 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.

As a Teaching Assistant for a first year computer science course, I have actually been using the example of writing an essay and keeping within a page limit by randomly cutting vowels out of words and thinking up ways to abbreviate words which aren't meant to be abbreviated.

Everyone quickly agrees that it would be ludicrous to do that. By stressing over and over, "try to write code which anyone could understand at a glance", I think they're getting it. Glad to see some like-minded thoughts!

Re: The Art and Science of Great Code

#14

Post by humbledrone »

gambler wrote: post #8
jon6 wrote: post #3

Failure 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.

Even worse than having to read weird abbreviated variable names is having to write them. You know the variable you want to write is something to the effect of "the number of buses", but then you can't remember if it's numBuses, nBus, nBuses, num_buses, or God knows what. It gets even worse when the original author starts dropping random vowels, so you have to guess nmBuses or nmBs or something horrible like that. Who knows what letters they decided to omit?

Much easier to just write out a clear, concise variable name with no abbreviations (other than those that are extremely obvious and common). Even if the variable names are a little longer, your text editor will autocomplete them (right?).

Re: The Art and Science of Great Code

#15

Post by dasil003 »

What separates good code from great is emphatically not style. It's the fundamental architecture. The omniscient vision to create a program that is somehow much more maintainable, much less likely to have bugs, or much more extensible than dozens of other potential solutions that any competent programmer would agree are "good". Great code can come from a combination of repeated iteration and deep thought, or it can be serendipitous, only emerging as great through the test of time. It's not only great programmers that write great code, and being a great programmer is no guarantee of producing great code consistently. It arises at an ideal intersection of mathematics, cognition, and utility. I hope to write some, someday.

Re: The Art and Science of Great Code

#16

Post by merlincorey »

kleiba wrote: post #4

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

Re: The Art and Science of Great Code

#17

Post by perfunctory »

kleiba wrote: post #4

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.

Re: The Art and Science of Great Code

#18

Post by humbledrone »

kleiba wrote: post #4

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 my younger years, I was extremely meticulous about tabulating anything in my code that was remotely tabular, but these days I pay less attention to that. Constantly re-aligning is a pain, as you mentioned. Another thing I've found is that it forces you to spend brainpower on decisions that are ultimately pointless. For instance, if the code is mostly tabular, but one line has an extra column, what do you do? Stick that column into an existing column? Add another column that will look weird with that one entry hanging? Etc.

Another really irritating result of lining everything up just so is that when you do a search+replace on a bunch of code, and change the length of an identifier. Suddenly you've screwed up the formatting on a bunch of tables without even knowing it! This is especially annoying with doing a search+replace across multiple files, with lots of code.

That's not to say that lining things up sometimes is a bad thing, particularly when you really have a table (e.g. initializing a big array of structs). Sometimes having things lined up makes it easier to edit later (e.g. using Vim's visual mode). But I'd say that 90% of the time, it's a waste of effort that could be spent, say, making your code actually work better, rather than look better.

Re: The Art and Science of Great Code

#19

Post by perfunctory »

Silhouette wrote: post #7

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?

I sort of agree. When it comes to coding style there are too many opinions and not enough scientific evidence.

Re: The Art and Science of Great Code

#20

Post by chubot »

dasil003 wrote: post #15

What separates good code from great is emphatically not style. It's the fundamental architecture. The omniscient vision to create a program that is somehow much more maintainable, much less likely to have bugs, or much more extensible than dozens of other potential solutions that any competent programmer would agree are "good". Great code can come from a combination of repeated iteration and deep thought, or it can b…

Yeah, when I was a less experienced programmer, I spent a lot of time formatting code. I made everything ultra-nice looking.

But you can only get 10% more readability this way. Any style is readable as long as it is consistent. You get used to reading non-aligned code, and the advantage of faster editing/diffs makes it better IMO to stop aligning it (I used to do that).

The real difference comes when you learn to break down your problems correctly, and control dependencies. Another way of saying this is to make the program structure matches the problem, rather than manually compiling lots of irrelevant details.

Part of the benefit is that you literally will have fewer lines to read. There will be fewer lines of code, and you will have to read and understand a smaller portion of the code to make a given change.

Code formatting is just a small part of maintainability. I agree this article seems "small".

Post reply on HN