Freigeben über

What does style look like, part 8 (the end)

  • Artikel

So over the course of the past week, I've spent some time talking about various things that make up a program's "style". 

There's one final aspect of programming style that I want to touch upon, and that's "Literate Programming".  Literate programming got its start with Donald Knuth's seminal book "Literate Programming".  The entire TeX project was written (or rather re-written) using literate programming.  Literate programming is in many ways the antithesis of many of the things I've talked about here - with a more traditional programming style, the code is the documentation, in literate programming, the documentation is the code.  The literate programming paradigm is a totally document-centric paradigm, in fact the code is almost irrelevant.  In the literate programming paradigm, your source code is a document, and the actually resulting program is built up by stitching together fragments of code.

When I wrote my compiler back in my senior year in college, I wanted to explore the idea, so I wrote my compiler using literate programming.  Here's a simple example:

58. Determine if the fields of a record are legit, and return a pointer to the type field of the rightmost field on the list Variable^.LHSOperand.

< Check and return the type of a record field access 58> ==
  with  Variable^ do
begin
      TSTE := Type_of_Var(LHSOperand);
       if LHSOperand^.NodeT in [Terminal, ProCall] then
          RValue := Type_of_Record(IDList, TSTE)
      else
begin
          SemError( 'Huh? Record fields can only be identifiers or arrays', Error);
          UnParser(TTY, Variable);
          end;
      return;
     end

This code is used in section 57.

Section 57 had:

  if  Variable^.NodeT == LValue then
< Check and return the type of a record field access 58>;  if ....

Literate programming isn't a style for everyone (I'm sure that the literate programming people are going to be mad at that statement), going back over my compiler, in retrospect, it's clear that I didn't do a great job of living up to the paradigm, but it IS a viable form of programming style.

 

As I've pointed out, there are literally dozens and dozens of ways of writing a particular piece of code, and all of them are "correct".  The differences between those representations is what brings "style" to a piece of code.

And just like fashion, coding styles have had trends - various coding constructs come in and out of style - for instance, currently exception handling is in, and error codes are out.  This may (and likely will) change as time goes on - time changes peoples perceptions of the value of various constructs (there was a time when structured error codes were the rage - that particular fad climaxed in x.500 error codes, which were highly structured entities that encapsulated not only the error, but the reason, recommended action, etc.

Over time, every developer comes up with their own particular style - it may be the style that their mentor (or team) used, it may be the style that was in a piece of code they admired, it may be in a construct that they ran across in a textbook, it might just be from hard experience.

Ultimately, the purpose of having a coding style is to result in more maintainable code.  Even if your code will only ever be used by you, having a consistent style is STILL critical - you're still going to have to maintain your code, and if your code is internally inconsistent, then you're going to struggle when you go back to that old code.

I've got to say that I was reasonably pleased when I went back and looked at my old code for this series - there were some seriously cringe-worthy bits, and the quantity of comments was scarcer than it is today, but overall, it wasn't that hideous.

If you're working on a team, it's even more important that you have a single coding style (or rather coding conventions).  As I pointed in this article last week, if you don't have a single coherent coding style, all you get is a mishmash, and mishmashes are rarely maintainable (and yeah, the spelling checker had mishmash in it).

Coding style brings together individual and team discipline, personal esthetics, and a little bit of magic to make a coherent whole.

Tomorrow, what does my personal coding style look like?

Comments

  • Anonymous
    November 18, 2004
    The comment has been removed

  • Anonymous
    November 18, 2004
    Actually I'd thought about it, and planned on putting it in, but kept on forgetting it - it belonged in the "effective whitespace" section :(

  • Anonymous
    November 18, 2004
    Larry,

    >> Ultimately, the purpose of having a coding style is to result in more maintainable code.

    exactly. thank you very much for mentioning this. unfortunately, not a lot of people understand this. now i have a 'reference' to point to. :)

    WM_THX
    thomas woelfer

  • Anonymous
    November 18, 2004
    As much as I dislike exceptions (I'm in the Joel camp on that one), MS has pretty much assured that exceptions will be The Way for however long the CLR lasts.

  • Anonymous
    November 18, 2004
    The comment has been removed

  • Anonymous
    November 18, 2004
    Mike,
    I'm not so sure. The "exception vs. error code" debate's still raging internally, it's actually fascinating to watch.

    I've grudgingly started to realize that if you're very careful and use RAAI exclusively, it MAY be possible to write code that correctly handles exceptions, but...

    It'll be interesting to see how it plays out. One thing that's become utterly clear is that it's almost impossible to handle cross-domain exceptions - so taking SEH and handling it with C++ exceptions is totally fraught with danger, and taking COM errors and turning them into managed exceptions is only problematic.

  • Anonymous
    November 18, 2004
    I am both a fan of RAII and not using exceptions. I have yet to find any evidence that exceptions help you produce more bug free code. Like many things all you are doing is trading in one set of problems for another.

    Larry, I would love to hear your thoughts on whitespace. I for one am always telling my guys to "PLEASE FIND THE SPACEBAR". :)

    if(bob.frank->tom()<42||flag==true)
    {
    ...
    }

    And don't get me started on why they decided that doing "flag==true" is a good thing especially in the case of testing for TRUE with BOOLs. I don't know if it was you or someone else, but I loved the article on not mixing your integer and logical operators.

  • Anonymous
    November 21, 2004
    The comment has been removed

  • Anonymous
    November 21, 2004
    11/21/2004 1:47 PM Michael Grier

    > "If exceptions are the answer, umm... what
    > was the question again?"

    "How do you bring peace to the Mid-East?"

    (This is just a not-really-parallel variation on an old joke.)

  • Anonymous
    November 22, 2004
    The comment has been removed

  • Anonymous
    November 22, 2004
    > What does style look like, part 8 (the end)

    OK ... the end, except for feeback ^_^

    > Tomorrow, what does my personal coding style
    > look like?

    Hmm ... looks like null, because the series ended yesterday? u

    Now checking ... yup, today's posting is null, at least so far ^o^

    By the way a cat owner's smiley looks like >^.^<

  • Anonymous
    November 22, 2004
    Actually it didn't. But I'm on thanksgiving vacation (thus the blog's dark), and that post is in the office.

  • Anonymous
    November 22, 2004
    "The point is the amount of information about failures, and removing the need to have redundant code in order to handle failure cases."

    This is part of the problem. When it comes to exceptions, everyone has their own opinion about what problems they solve. There are many people who feel what you describe is exactly what exceptions are NOT intended to do. They are intended to handle "exceptional" conditions, not to handle failure cases (and there is a HUGE difference).

    As far as getting all that "fancy" exception information from an exception, that is implementation specific. You don't get that information using SEH or C++ exceptions as defined by their design or the standards.

  • Anonymous
    November 22, 2004
    The comment has been removed

  • Anonymous
    November 23, 2004
    The comment has been removed

  • Anonymous
    March 15, 2006
    Well, this year I didn't miss the anniversary of my first blog post.
    I still can't quite believe it's...

  • Anonymous
    September 07, 2006
    PingBack from http://www.ljseek.com/on-c-error-handling_13761091.html

  • Anonymous
    June 15, 2009
    PingBack from http://unemploymentofficeresource.info/story.php?id=11365

  • Anonymous
    June 16, 2009
    PingBack from http://workfromhomecareer.info/story.php?id=27303