Fog Creek Software
Discussion Board

Teaching good coding sytle in Uni

In the "I finally found one!" discussion
someone mentioned that they should teach students to use the if( 3 == x ) style instead of the more common if( x == 3 ) style, for obvious reasons.

When I was in school, I asked a professor why they don't teach more about good programming practice, debugging, etc.  His response was: "If you could get 30 Computer Science PhD's to agree on a good style of coding, we'd have a class on it."  Obviously thats a losing proposition, so it wasn't taught.

Was anyone here taught these types of things in school?  Or did you just have to teach yourself reading books like The Pragmatic Programmer, Code Complete, etc?

Andrew Hurst
Thursday, July 3, 2003

My Data Structures and Algorithms class was taught by a woman who's day job was at a software consultancy, who came back to teach that class just to have a shot at impressing on students the importance of good coding practices.  Best professor I've ever had.  There were fewer details, like the x==3 vs. 3==x thing, than there was repeated, close examination of code snippets.  For assignments, there was a fairly simple style sheet.

The impression I left with was that the more important aspect of style is what writers worry about:  It's not "is it correctly formatted?", it's "is it clear and understandable?".

Justin Johnson
Thursday, July 3, 2003

My university studies concentrated heavily on good coding style, but not at the "if (3 == x)" level.  Mostly it was about proper use of abstraction, not duplicating code, etc

Mike McNertney
Thursday, July 3, 2003

It was CPS 586 (Operating Systems) before I saw the "if (3==x)" stuff. Barely anything about coding style. Almost all of the coding when I went through was done in Pascal. I took independent study on C, Lisp, and Ada. The C class was a pre-req for 568, because the code was all in C, but if they didn't take that path, the students had no exposure to C.

Brad Wilson (
Thursday, July 3, 2003

I do take points off for style, but it's hard to make that significant when half your students don't get what 'if' does.

The last semester we graded the courses labs on a recomendation basis only: as long as you do them, they get credit, but we make comments. *Lots* of comments, usually.

However, I must admit that most don't heed it at all. Those that write good code do so from the start, and the rest turn in their final assignments with horrible indenting. Blech.

Mike Swieton
Thursday, July 3, 2003

I should add that another professor I had once related this story to me about the intro to programming classes he taught (in C).

What he would do is assign about 5 programming assignments over the course of the quarter.  For the second or third assignment, he would pass back what people turned in for a previous assignment, but not to the author.  he would take off all identifying comments, and give them to someone else.  Then get the new person to add a feature.  After that project was turned in, he lectured a bit on writing maintainable code. 

He said that the 4th and 5th assignments were much easier to grade and read. :-)

Andrew Hurst
Thursday, July 3, 2003

That's brilliant!!

When I taught SW engineering, I gave an exam where the students got up to 30 minutes for design, but couldn't turn on thier computers.  Then when they turned on their computers to start coding, they had 30 minutes to write the program.

This really encouraged them to THINK about thier design.

I think it helped them quite a bit.

I think I'll start a thread on: "simple things that to teach sw engineers"

Thursday, July 3, 2003

For a long while I tended to write ( 3 == x ).  I tend to do it the other way round now, and not worry about it, as I've never actually fallen for = instead of == in an if in many years of coding. The compiler hopefully warns you too.  And the effect if some how it slipped by of accidental assignments, would probably be obvious from any reasonable amount of testing.

What I think more effort/ideas/thought should go into is in complex conditions involving several && and || and !.  Everybody gets some complex condition wrong in their programs once in a while - and some of them don't get noticed, until late, or even in production code.

S. Tanna
Thursday, July 3, 2003

Well, regarding complex conditions, IMO if you have lots of huge if's in many places, then that indicates that you have a problem with abstraction in your program.  People might accuse me of abstracting too much, but I think that is really the power of programming languages -- they allow you to create your own abstractions.  The code I'm currently working on has tons of complex if's, and if's duplicated (w/ slight changes sometimes).  Basically the main abstraction used is the programming language itself.  You have to think at the statement level rather than at a higher level.

Incidentally I don't see how that relates to 3 == x, since that is more of a typing/syntax problem, whereas the complex condition thing is a very important design problem.

Thursday, July 3, 2003

The condition is still there whether it's in separate function(s)/layer(s) or not.  I do not think human brains are wired to get complex conditions right enough of the time. If I understand your argument, it's reduce complexity by abstraction, which I would not disagree with.  That said, I don't think it is more than a partial solution.

In my experience many bugs are caused by conditions being slightly wrong

As to why I raised it, it simply seems a more real problem with if statements, than whether you write if (x==3) or if (3==x), which rarely seems to go wrong in actual use. The 3==x debate is based on what I consider a largely false premise, that bugs are caused by typos and not reading compiler warnings.

I think bugs are primarily caused by other factors: logic errors, design errors, inability to full comprehend code, bad-wiring in human brains, not considering all cases, etc.  And this is the area we ought to be trying to attack. 

Many of the primary causes of bugs stem from poorly understanding the code.  Abstraction can help.  So can simple things like writing code in more readable ways, which is why I think if ( x == 3 ) is at least as good as if ( 3 == x )

S. Tanna
Thursday, July 3, 2003

While I've been to college courses, I avoided compsci.  Still, how do you learn good style when people fight over what language should be taught?  In most languages, if(x = 3) isn't a problem to lose sleep over.

Indentation and commenting are the main thing that stays the same.  And I hear Horror stories about teachers getting the commenting part wrong.

Thursday, July 3, 2003

S. Tanna:

I agree that 3 == x is not really a major concern.  I don't use it but I could care less either way.  I agree with the first poster: there are very few absolute good coding practices of this sort.  Everyone has their own style, because everyone thinks about programming differently.

And I agree that many bugs are caused by conditions being wrong.  I think that complex conditions should be rarely used, and aren't necessary in many cases.  In the code I am currently working on, there is all sorts of code like:

if( A || (B && !C) || D )
  blah blah

if( A || (B && !C) || !E || F )
  blah blah

where A B C D are global state.  It's programming 101 to avoid this kind of thing, but it's of course widespread in practice.

On a mundane level, you can just say: goodNameHere = A || (B && !C).  And then you just have:

if( goodNameHere || D )


if( goodNameHere || !E || F )

This goes a long way.  But I'm saying that, even more importantly, if you have designed good abstractions, then a lot of the ifs dissolve away.  For example, I'm working on some user interface code now, where basically every thing is done with ifs and switch statements.  It is about 10 times more code than is necessary.  It sorely needs some very well-known abstractions that are used in UI code like the APIs Microsoft and Apple have designed for the OSes (flawed though they may be, they're still better than writing UI code in a 1975 top-down style).

Just creating a polymorphic interface can eliminate a lot of ifs as well.  Polymorphism forces you to make the abstraction when you write your code, which is a good thing.  In C, using opaque pointers instead of directly accessing member tends to take a lot of ifs out of code.  Many ifs can be hidden in the "private" functions that manuipulate the structure.

I don't know if I am describing this very well, but in short I think that a lot of complex ifs are caused by design problems.

Friday, July 4, 2003

> I don't know if I am describing this very well, but in short I think that a lot of complex ifs are caused by design problems.

Definitely "some", possibly "a lot", definitely not "all".

Some situations are complex by nature, because the rule that the computer is modelling is itself unavoidably complex.

I'm sure you can find many real world examples (and these aren't cauise some, but not-all complex, and un-simplifiable*, conditions in software, some may arise for internal reasons in the software too).  For easy to find, real world examples, a good place to start looking might be business rules, tax codes, etc.

* Of course you can simplify any condition by wrapping part(s) of it in external function(s).  But I'd argue that it is only truly simpler if the external function actually corresponds to something coherent that you can brain can take in, not so random of lump of &&s and ||s

S. Tanna
Friday, July 4, 2003

Actually, if you think about it, the Python community is remarkable.  They're always asking, "Is this Pythonic?  IS THIS PYTHONIC?  PYTHONIC???"

I think the moral is if you care about the Usability of a language, users will care too.  C doesn't inspire me to care about how code looks.  Whereas with Python, I think, "Well, people have had enough time to get used to list comprehensions, why don't I stop using map/filter?"  And it's kinda silly because a lot of this code might never see the light of day, but I would feel ashamed if I wrote code that the greater Python community wouldn't understand syntactically.

Saturday, July 5, 2003

"Just creating a polymorphic interface can eliminate a lot of ifs as well."

The Refactoring book says something to the effect of 'every conditional should make you wonder whether a refactoring wouldn't be better', for just the precise reasons you mention. You turn:

  if (isUserAdministrator) ...

into polymorphism, by separating normal and admin users and the things they do. That was pretty eye-opening advice the first time I saw it. :)

Brad Wilson (
Saturday, July 5, 2003

The isAdmin idea is a good point, if the situation is as simple as that

What if:

Alice isAdmin isProgrammer
Bob isProgrammer
Charlie isAdmin
Dave isProgrammer isManager
Earl isAdmin isManager

What happens here when you want to test these attributes? Multiple inheritance (a controversial topic in itself)

Alternatively what happens if your decision point (isAdmin) is not the same as your class hierachary (let's say your classes are based on job title which is not necessarily related to isAdmin). Again multiple inheritance, or decision points in one case

S. Tanna
Sunday, July 6, 2003

But your decision about the adminness or programmerness of someone should _never_ be based on the class hierarchy. You have a function that says true or false depending on the adminness of the object.

No hierarchy needed. (Well, apart from that mandated by the language. For example, you can't say "thing->IsAdmin" polymorphically in C++ unless the common base class has an IsAdmin function.) And that is I think as it should be; for if you are using the runtime type of the object, that is hardly polymorphism!

An additional point is that any rule is always wrong sometimes. I may start another thread about this soon, because this seems to be the root of many arguments.

Sunday, July 6, 2003

If it's not internal to the class, then the condition returns somewhere, which is my point.

S. Tanna
Monday, July 7, 2003

*  Recent Topics

*  Fog Creek Home