Scribd
Upload
18 views2 pages

Coding Standards

The document discusses different levels of coding quality from lowest to highest: no-one-will-look, peer-review, publication. It recommends aiming for publication quality and writing high quality code from the start with good decomposition, comments and names. Well-designed code will be easier to maintain and have fewer bugs.

Uploaded by

joseht.adrian
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
18 views2 pages

Coding Standards

The document discusses different levels of coding quality from lowest to highest: no-one-will-look, peer-review, publication. It recommends aiming for publication quality and writing high quality code from the start with good decomposition, comments and names. Well-designed code will be easier to maintain and have fewer bugs.

Uploaded by

joseht.adrian
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 2

Coding Standards

© Nick Parlante, 1996.Free for non-commerical use.

Landmarks in Coding Quality


Let's honestly review the conceptual landmarks most programmers use when thinking about how
good their code is:

Publication Quality Code suitable for publication in an article or textbook. Perfect


algorithm, thoughtful overview and inline comments, perfect formatting, all the
identifies make sense, no coding hacks of the slightest vulgarity. Something you'd be
proud for anyone else to see- you'd include it with your Stanford application. No one
writes code like this by accident. It has to be a deliberate goal from the beginning.

Peer-Review Quality Some companies have "peer code review" meetings every once
in a while where a programmer hands out printouts of whatever they've been working
on and then walk all their peers through it so they get the gist of what's going on. Most
programmers dread peer review because much of the code they whip out from day to
day is a bit embarrassing. Companies like peer review because it scares the programmers
into avoiding embarrassingly bad code. So Peer review quality code tends to be mostly
pretty good, but with occasional lapses that can be rationalized to an understanding
audience- "I was going to decompose that, but I didn't have time." " oh yes, ha ha, on
page 8 there're are some utterly awful looking functions I whipped out to fix that VM
leaking bug we had in May. I don't think it will port to the HP anyway. I think we're
going to make the summer intern re-write it." "I'm going to go through and write
documentation for that module and fix the variable names just as soon as I finish this
current project I'm just right on the verge of finishing. Real soon now. I promise. Stop
laughing at me!"

No-One-Is-Ever-Going-To-Look-At-This-Again Quality Code that's just being


whipped out to solve something. No overview comments. A lot of one letter variable
names. Indentation and whatnot tend to be ok just out of habit. Instead of decomposing
out common functions, the programmer will just copy and paste swaths of code.

Look-At-Me-I'm-So-Smart Quality This is a programming habit you'll see in parts of


programs. As with many other disciplines, some programmers can't resist the pleasure
of noodling around in the obscure parts of a language. This is fairly understandable
really— programming languages are arcane creatures, and there's something pleasing
about cranking hard on some obscure construct. But it's not a useful impulse. It tends to
go something like this..."By eliminating all the function calls and using this other
obscure platform specific feature that no normal person has ever heard of, I was able to
reduce your whole program down to:

for(;P("\n"),R-;P("|"))for(e=C;e-;P("_"+(*u++/8)%2))P("| "+(*u/4)%2);

It's a full 24% faster, and it only took me a day." Efficiency is often cited. This impulse
seems to come up in meetings and lectures as well.
2

What's Impressive
Just for reference, here's the offical chart of what's impressive and what's not, as published by the
Opinionated Programmers Council headquarted in Geneva Switzerland.

• Code which works for all cases Impressive


• Code which was finished on time Impressive
• Code you didn't write, but got stuck with somehow,
and yet find easy to deal with and maintain Very Impressive
• Elegant and clean code with the occasional bit of
inspired cleverness Impressive
• A complex and highly hacked up and optimized computation
packaged in a nice, painless to use abstraction. Impressive for Implementor
Fun for client
• Nice looking code which runs fast and ports with no work Impressive

• Code which works on many, but not all cases Not Impressive
• Nasty looking code which is a pain to read and debug Not Impressive
• Thoughtless code which took little time to write Not Impressive
• Fast code which doesn't work quite right Not Impressive
Stanford CS Standards
In a Lord of the Flies, uncivilized incarnation, many programmers will slip into No-One-Is-Ever-
Going-To-Look-At-This-Again style code. Whatever takes the least time to type. But that habit
doesn't translate well in real world where programs need to work, get maintained, etc. On the other
end of the spectrum here at Stanford, all we do is write, read, and think about code and how to
write it better. Even if rarely attained, we should at least hold out Publication Quality as an
interesting ideal to think about. Peer-Review quality might still get an "A". Mediocre looking code
which computes the right answer should get a "B". When writing code, at least be honest with
yourself about what level you are aiming for, and start early enough to have a reasonable chance of
succeeding.

Write The High Quality Version First


For a hard programming project, it's tempting to use the following strategy: whip out a low-quality
solution with no decomposition and one letter identifier names just to get something working. Do
most of the debugging work on the low quality model. If there's time once everything is pretty
much working, improve the decomposition, identifier names, etc. to get the program up to the "A"
level. Thist strategy has been tried quite a bit, and it doesn't work. It's easier to write it at the "A"
level right from the start. Well decomposed, readable code will have fewer bugs, and what bugs
there are will be better isolated and easier to track down. Realistically, most of your development
time is not going to be consumed by typing in long identifier names or writing two 15 line
functions instead of a 30 line one.

One Pass Coding


It's more work to retrofit a feature at some time after the original coding. The first time you write
something, you have all the details in your head. It's the easiest time to put in comments, extra
features, etc. Every time you revisit the code later for debugging or revision, there's a period of re-
learning while you remind yourself how the thing works. This becomes a real problem when your
programs get seriously large.

In the "one pass" model, you try to write things well enought the first time with the goal that you
will never revisit most of it. Of course with the unpredictability of debugging and unplanned
design revisions, you will certainly revisit some parts of your program. But if you choose a
strategy of revising the whole thing later, then you will certainly need to relearn all of it, and that's
going to take much more time than putting in the extra effort to fix things up on the first writing.

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy