Slashdot Mirror

← Back to Stories (view on slashdot.org)

Defining Useful Coding Practices?

Posted by Soulskill on from the randomized-variable-names dept.

markmcb writes "A NASA engineer recently wrote about his disappointment that despite having well-documented coding practices, 'clever' solutions still made the code he has to maintain hard to follow. This got me thinking about the overhead spent at my own company regarding our code. We too have best practices that are documented, but most seem to focus on the basics, e.g., comments, modularity, etc. While those things are good, they don't directly ensure that quality, maintainable code is written. As the author points out, an elegant one-liner coupled with a comment from a few revisions ago makes for a good headache. I'm curious what experience others have had with this, and if you've seen manageable practices that ultimately offer a lot of value to the next programmer down the line who will have to maintain the code."

7 of 477 comments (clear)

  1. Best practices only go so far... by djpretzel · · Score: 3, Informative

    "Quality" can be both objective and subjective, and it seems this post is leaning towards the latter in terms of what it's getting at... while I believe in having formalized guidelines of some kind, I've found the best way to seek out and improve the elements that can't be easily quantified is through (drum roll) code reviews/walkthroughs. It seems like these are rare, at least where I'm at, and it's hard to get buy-in when you're talking about contractors charging by the hour, but in my opinion a single quality code review can save TONS of time down the road and is necessary for projects over a certain size. Also, read "The Pragmatic Programmer" and "Code Complete" for some of the best guidance on this topic.

  2. Code Reviews (Gerrit) by jtolds · · Score: 2, Informative

    Traditional everyone set aside time and review checked in code is hard to do, difficult, and time consuming.

    On the other hand, automated code review tools are life changing. There's a bunch of tools out there, but the one I think is far and away the best is Google's Gerrit tool (http://code.google.com/p/gerrit/), which is what Google uses publicly for Android.

    I cannot understate how helpful Gerrit has been in this regard. So many things that are trouble down the road are easily caught by even just one other pair of eyes. Everyone who has used Gerrit at my compnay has fallen in love with automated code reviews. It's refreshing, leads to better code, etc. I seriously could gush about Gerrit for pages.

    1. Re:Code Reviews (Gerrit) by gbjbaanb · · Score: 2, Informative

      It seems that's for git only, if you want a similar code review product (that's web based) you could look to VMWare's OSS ReviewBoard which is more source-control tool neutral (requires python) and can be automated according to your SCM tool.

  3. Re:multiple revision? by daedae · · Score: 2, Informative

    Unless of course they meant a one-liner coupled with a comment from the previous implementation, ie, the clever programmer failed to cleverly update the comment.

  4. author seems somewhat confused and inexperienced by bcrowell · · Score: 5, Informative

    The author of TFA seems somewhat confused and inexperienced.

    1. "Most of the variables in CRAP are one or two letters long. Originally, this was due to the memory constraints involved when programmers first designed and built the system." This is not particularly plausible. C is a compiled language, so using long variable names has no effect on the amount of memory used at run-time. It would also have been more or less a non-issue in terms of RAM used at compile-time. C only dates back to 1972, and didn't start to get popular until ca. 1980. By that time, using long variable names would have had a pretty negligible effect on RAM used by the compiler in proportion to total available RAM. And in any case, if compiles are taking too long, you just break up your files into smaller parts.
    2. He uses this code "for(ss = s->ss; ss; ss = ss->ss);" as an example of bad code: "For those of you that are interested, the line traverses a linked-list of sources and sub-sources to process the values inside. But it took a good deal of research to figure that out, because there were no comments and the variable names, well, suck." Well, I read that and said to myself, "It's traversing a linked list." I think what's really going on here is that the author is probably a programmer who learned to program relatively recently with C++ and Java (he says in TFA that those are the languages he's used to), and he's used to doing things with big OOP libraries. The culture he's been inculcated in is one in which you never have to understand how a linked list is actually implemented, because you just use a library for it. To anyone who's actually implemented a linked list in a language that uses pointers, it is fairly obvious what this code does. It shouldn't take "a good deal of research" to figure it out.
    --
    Find free books.
  5. Re:Linked list by ysth · · Score: 2, Informative

    That doesn't seem to be the case here; s is a "source", s->ss is the source's list of "sub-sources". So the s and ss names are just accurate abbreviations, not an example of your "x" and "xx" phenomenon. The "next" pointer for a sub-source itself being named "ss" is a little strange though.

  6. Re:author seems somewhat confused and inexperience by Anonymous Coward · · Score: 2, Informative

    C is a compiled language, so using long variable names has no effect on the amount of memory used at run-time

    It does if you're embedding symbolic debugging information in that same binary - and running it on a system where the entire executable is loaded into memory at start, rather than paging in sections as needed.