OpenBSD Journal

Cleaning Up Code

Contributed by jose on from the sweeping-it-up dept.

Rick Wash writes: " http://marc.theaimsgroup.com/?l=openbsd-cvs&m=107585763312294&w=2

One of the great things about OpenBSD is that the core team makes a very concerted effort at keeping the code extremely clean and readable. This greatly fascilitates finding and fixing bugs, and is one of the things that makes OpenBSD so stable. It also helps make OpenBSD a great platform to develop on.

The best example I've seen of this recently is this commit message: 

"8579 lines of KNF, ANSO and zap-junk diff without the
resulting binary changing by a single byte."
Now that's a code cleanup. Thanks a lot Henning and Theo and the rest of the OpenBSD team!"

(Comments are closed)

Comments

  1. By joe bloggs is a sysadmin () on

    There are still big and obvious bugs, like with the umass code, where removing a umass device without umount first causes the system to eventually lock up. And a panic occurs when taking a picture with a bktr card and ctrl+c in the middle of the snapshot.

    Comments

    1. By fips () pb@ on mailto:pb@

      you didnt get it, right?

      or is this "whoa, first post! let's troll!"?

      *sigh*

  2. By fips () pb@ on mailto:pb@

    art@ brought it down to the point, why
    readable, "nicely" formatted code is important.

    Read "Write-only code." on
    http://www.blahonga.org/~art/rant/index.html

  3. By Anonymous Coward () on

    probably one of the best examples of good C I've seen is init(8) (/usr/src/sbin/init)... simple, legible, maintainable, reliable... *sigh* I wish all the code at work was written so well...

    Comments

    1. By Anonymous Coward () on

      So is this a piece of code you'd recommend for c newbies? I.e. reading these pieces can actually teach you not only what it's all about but also a good programming style?
      Regards

      Comments

      1. By Anonymous Coward () on

        it's not really for newbies - mostly because it uses (and uses well) some fairly advanced techniques and a fairly non-intuitive design (well... that's my opinion, but I know I wouldn't have wanted to deal with a state machine 9 years ago - now that I've seen how badly that can be done I'm only more impressed with init).

        For a newbie I'd recommend starting with what's in /usr/src/bin - these are mostly very small, focused programs that perform exactly one task, and do it well. You'll find a few complex programs there, but just skip over them and come back when you're ready. Very importantly: read the man page for that program first, and play with it a bit to see exactly what it does and how it behaves under what conditions, then jump in and figure out what makes the code behave like that.

        Never forget - a debugger is a great tool for understanding how code works, as it works.

  4. By Anonymous Coward () on

    What does "KNF" and "ANSO" actually stand for?

    Comments

    1. By Brad () brad at comstyle dot com on mailto:brad at comstyle dot com

      ANSO was a typo for ANSI and KNF stands for Kernel Normal Form. Look at style(9).

Latest Articles

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]