On Smalltalk

You suggestions still include gratuitous use of "else". E.g., you wrote:

if(someCondition) return "foo"; else return "bar";

Just do this:

if(someCondition) return "foo"; return "bar";

Correct you are, minor oversight on my part from cut and paste. Fixed.

Hi,

I really like your blog. Please continue posting often.

Bye

Yay. Woo.

You are a moron.

"A method should be 7 to 10 lines of code..."

I've always been a heretic on this one. Usually when I see these forests of short functions, I see functions created solely to make each one short.

A function should be as long or as short as it needs to be to do what it does. Cutting out a bit of its insides to make a new function buys you nothing in terms of understandability of the whole, and costs you a context switch when the machine executes it and when a programmer understands it.

Can I just ask what is the problem with using braces?

is if(condition) {
statement; }

that offensive to you?

"You are a moron."

The proverbial pot. Where is your explanation of "moron"? Are you of the "Battleship Principal" mentality? Good thing guys like me get paid better money to refactor your code.

Contrariwise, I always see people cringe at grotesquely large functions but seldom do I see cringe at oversized classes. A class with a hundred members and a hundred methods is just as wrong, usually, as a function of a thousand lines.

I just came here from Reddit from Robert's Shared feeds in Google Reader. I just wanted to let you know that you might want to tweak your come from Google message up top for Google Readers, so they won't see it. ;)

One of my pet peeves is a hundred 7-10 line methods that exist only because the self-fellater who wrote them thinks methods were invented to replace comments.

Seriously, though, I agree with you on almost all of these. I hope you write a sequel.

I cringe at over sized classes as well, though much less so in Smalltalk, where I can organize a large number of methods more easily. Look at Object for example.

Thanks for the tip on Google Reader, I'll have to take a look at that landing page plug-in.

Des, I don't use braces unless it's a multi line statement.

"A function should be as long or as short as it needs to be to do what it does"

Agreed Craig, and that averages out to about 7 to 10 lines of code, if you're keeping to the rule that a function should do one thing. As with all things, there are always exceptions, I was referring to the average.

I disagree with not using switch statements because they can be replaced with an OOP solution (not that I understood what you meant) but for the simple reasons that OOP per se isn't the only solution out there (as far as design/method). Otherwise, good overall assessment and an enjoyable read.

I agree, he is a moron.

I can see him as a monk in the Dark Ages, constantly fasting, constantly accusing the style of the other monk's prayers as being incorrect and insufficiently pious.

Some of the stuff that bugs him is done on purpose; some people just think it is clearer (easier to follow).

You must have missed the part where I said "My" personal pet peeves.

You've obviously been reading my mind, Ramon. Stop it.

I agree that code style should be consistent and avoid unnecessary fluff.

XML is awful for configuration files. That file is there for me, the user/administrator, not the program. I want to be able to read it, and I want a higher ratio of actual-content to structure when hacking it.

I usually just do a: return condition ? "foo" : "bar";

... but I have a strange obsession with that operator. I'm a TA for intro Java at my university, and one of the things I can't stand is when students:

result = someOperation(); return result;

instead of just return someOperation();

Good post, I might actually print this out for my intro class tomorrow morning!

if(someCondition == true) doSomething();

• adds clarity

string result = ""; if(someCondition) result = "foo"; else result = "bar"; return result;

• standard approach, consistency and style

My pet pea is many lines of code commented out. If you're confident enough to check in code that you've commented out then just delete it! You are using source control right?!?

This doesn't bother me, because it reads just like a business rule:

if(foo == true) { // stuff }

When people write: if(foo) { // stuff }

I can't help but dart my eyes back up and make sure 'foo' really is a boolean (I'm still doing that in Java...a left over from my C++ early days, I guess).

If you think

if(someCondition == true)
    doSomething();

adds clarity, then I assert you aren't groking booleans, as I said in the article.

There's nothing about it that makes it clearer, since we all know that "if" takes a boolean parameter and tests for true. It's totally redundant and useless to compare true to true to see if it's true. BTW, I'm not talking about C or C++, I'm talking about C#, Java, Smalltalk, Visual Basic, more modern languages.

I agree with the deleting of commented out code when using source control however, also a peeve of mine.

Mostly ok, but you can pry my error codes from my cold, dead fingers.

And thickets of little functions called from one place each are not a big improvement from over a larger function. Yes, huge functions are a sign of problems, but slavish adherence to a strict small limit is not the solution.

LOL, nice, but it's not small functions I'm adhering too, it's using functions to do one thing, them being small is a simple side effect of doing so. As with all things, there are always exceptions.

I guess if no one else actually ever looks at your code, not using common sense prefixes makes sense.

[Isaac] Having a single point of return is supposed to make it easier to ensure all your allocations are released before you get there.

[Ramon] It's an amusing list and I agree with much of it, but way too full of OO dogma. Refactoring every choice into a subclass is just cruft 9 times out of 10. Error codes are often cleaner than exceptions, which are one of the classic "false sense of security" language features.

XML and Hungarian notation are absolutely the work of the devil, though...

You know what annoys me? High-minded knitpicking.

But really what annoys me is when people don't use descriptive variable names, they use names like m,n,a,b,c,i,j,k,r,s,x,y,z in some complicated method instead of names like maximumNumberOfExceptions.

Oh yeah, that's another thing that annoys me, when people don't follow naming conventions.

But mostly the high-minded knitpicking.

I didn't say every choice, but if something grows beyond and if/else if, I'll move to classes.

"I guess if no one else actually ever looks at your code, not using common sense prefixes makes sense."

Wrong! The IDE is there to assist you. If you changed an int to a string and named your variables as such (and didn't change your variable name), you just caused an issue for the programmer that follows you. Why the hell should sSomeText be a string? The compilers handle English statements, write Englsh. Some text should be someText.... just as it would read.

Good to see a Smalltalker still doing Smalltalk. however i disagree about single exit points, ^ (someCondition) ifTrue:["foo"] ifFalse:["bar"]. is cleaner then (someCondition) ifTrue[^"foo"] ifFalse:[^"bar"].

less code = simpler, cleaner.

wow the author needs to get a fucking grip.

You didn't have to work on the 3rd party code that I did today. This article didn't come from nowhere!

1. Ive read that its bad practice to have multiple return statements in a function.
2. Turning everything into an object is not good either..when it can be expressed with a primitive type

My Personal Pet Peeves I See in Other People's Writing: the incorrect use of the apostrophe drives me nuts. I often feel that they need to stop watching so much tv and start reading more books. A good one to start with is Eats Leaves & Shoots.

It's 3rd, not 3'rd. Use an apostrophe when it's a contraction, not a plural, or some sort of abbreviation, or possessive.

I'm still on about error codes. Somebody needs to explain to grandpa here why exceptions are so great? Maybe tomorrow's blog?

Like exceptions, error codes can be ignored by the part of the code that doesn't care. Unlike exceptions, they don't stop you in your tracks and don't trigger an allocation (the exception) and an expensive stack unwinding. Error codes and token values (eg NaN and, yes, NULL), when used correctly, are a great aid in smoothing out the bumps.

This makes me want to explode!?!

Wait... wait...

I have exploded!

Rusty, if this were a blog on the English language you might have a point, but it's not, it's about programming. Yes, I make the occasional mistake with apostrophe, who doesn't, get over it.

There, it's correct, you feel better now?

I find length of methods can have a lot to do with platform. When I write java code, length can often be par for the course. 7-10 lines is what I need just to get the variables set up. In ruby, however, I find it takes effort to write a method longer than 15 lines. Sometimes, but usually, this is because there's a better technique of which I was not aware. Or I was lazy.

I don't think it's correct to critique the many small methods argument, though. If your objects are properly scoped and structured, you won't have endless thickets of methods. Most very small methods' contents can safely be ignored, unless you designed them poorly, or named them poorly.

Naming is the lost art of programming.

"Like exceptions, error codes can be ignored by the part of the code that doesn't care."

The problem lies in the fact that error codes can change from programmer to programmer whereas exceptions, in the languages that use them, are a part of the framework and part of the programmer language set. By you defining your own error codes you try to reinvent the wheel or the language. If programmers coded with a parallel standards, such as an exception framework, there would be less time spent on trying to understand what the previous programmer was thinking.

It's true that exceptions used to be expensive, but that's hardly the case anymore.

Exceptions can't be ignored without explicitly coding around them, totally unlike error codes.

"A good one to start with is Eats Leaves & Shoots."

Next time you try to correct someone and recommend a book, you might come off as slightly more clever if you get the title and punctuation of the title correct--Eats, Shoots & Leaves.

Also, arguing about punctuation? Is that all you got?

It is so good to hear the views of another former Smalltalker. It is obvious from the comments here who has a clue about OO and who does not.

A coworker of mine just wrote an article about the declination of OO... http://allenriddle.com/articles/ooInTheEnterprise

The idea behind most of my programming style is to increase readability. I will read the code I wrote many more times than I write it. With that in mind, I always use braces for the bodies of ifs, even if they are one-liners, and always have an == in the condition of all ifs and whiles, etc.

I agree with you on multiple return statements. The function should have a single purpose, and if that purpose can be fulfilled immediately at any point, the function should stop. The only reason to have a single return point is to avoid problems with required side-effects or to allow a function to accomplish mulitple things, which you shouldn't be doing anyway.

Hungarian notation, used as you mention, is also garbage. Putting an "i" at the start of a varialble because it's an integer is nearly 100% useless and distracting, and just one more thing to screw up maintenance wise down the line. Instead, the reason for the variable being an int in the first place should be in the name, such as a "Count" or "Index" suffix.

As for error codes versus exceptions, correctly written code needs to prepare for and deal with the possibility that every statement or function call performed will fail. Exceptions don't make properly handling the errors any easier or more elegant or prettier, they just make code that doesn't do correct error handling look better. A construct such as:

if (DoSomething() == false) { //it failed. }

Is preferable in every way from coding time to runtime over

try { DoSomething(); } catch (DoSomethingsException e) { //it failed. }

Furthermore, not coding in the try/catch blocks around everything that might throw exceptions leads to some really horrendous problems. The worst such problem is probably the exposing of the implementation details of one sub-system to systems which use it only indirectly. For example module A calls module B, which calls module C. A has no idea about the existence of module C, but all of a sudden if module B doesn't handle its calls to module C correctly, module A is exposed to exceptions generated by module C that it had no way of predicting at coding time would occur and will therefore not handle properly.

I can agree with some of your sentiments, however many of your claims are a tad short sighted. Plus you deserved to be shot for your comments are garbage collection-- it is not a heaven sent-- more often than not, it introduces more issues than it aims to resolve.

Maybe the whole code-size thing can be summarized by saying whatever method forces the reader the least amount of "scroll around effort", is the right way to code it.

Thank you, this was great. I whole heartedly agree, except:

I tend to put code into a separate function only when more than 1 place needs to use the code, although I admit my code would naturally refactor itself if I followed your advice.

I love switch statements. Many times when I go down the polymorphic path I end up with harder to understand code. Sometimes its good to see all the logic in front of you in a switch statement instead of spread across derived classes.

Thanks again for the fun read.

I agree with most of your comments but two in particular stand out as rather strange.

Refactoring all your code into 7-10 line methods does not make it more readable, it means your are constantly switching around looking at each of the different methods to work out what is actually going on. My rule of thumb is that when a function hits 70 lines you should break it up.

Equally your point that effectively code should not be commented is crazy. This is like the argument that that code without comments is the documentation. At the very least comments should be there to document what is happening. For example some highly optimised code may be incomprehensible without comments. Anyway, you will tend to end up with very long method names.

I'd go 50-50 on your argument against switch. This basically assumes you have objects in the first place. Suppose you are parsing a file and grabbing elements that are parsed into objects. Sure you can create polymorphic objects that represent the different lines parsed from the file, but you will need a switch statement or a series of if else to work out which object to create in your class factory.

You don't need to switch around to look at different methods to see what's going one, the method name should tell you that. That's the whole point, you shouldn't need to see the implementation 95% of the time, just the name.

Good naming is what programming is all about. There's a reason the Smalltalk browser dedicates half the window space to category, class, method category, and method names, and only a small window to code.

Methods should do one thing, that's what determines when you break up code, not length. However, a nice side effect of this practice, ends up being lots of short easily understood methods.

Comments should "NOT" document what is happening, code does that perfectly well. Comments should only explain why certain choices were made, they should never duplicate what the code says.

As for switch statements, parsing is one of those exceptions, switch statements are useful here. I said there was hardly any case where they were appropriate, I didn't say they were never appropriate.

"Intolerance is the hallmark of a small mind." While I understand your point in all this, 'black and white' rules have no place in software. For every rule, there is a damn fine reason for not following it. The key to being really, really good in this field is to know that EVERYTHING has tradeoffs.

Offer these as 'guidelines' not absolutes. You will appear to be much smarter.

"Constantly jumping through hoops and writing extra unnecessary code just to have a single return statement in a method"

string result = "";
if(someCondition)
   result = "foo";

else result = "bar"; return result;"

I'm still a pretty basic level programmer but the visual studio compiler throws a compile time error if you try to not do something like the above. If you specify a return value in a method header and put all the returns in a conditional it throws an error saying "not all paths return a value".

Jeff, if you actually read the post, you'd see it was meant partially in jest, hence the overly strong language here and there, and on more than one occasion, I've said as with everything, there are always exceptions.

The post is also titled "My Personal Pet Peeves", which obviously means these are opinions and not absolutes, so lets not preach too much about how to appear smarter.

Dan, don't use the else, it will compile just fine.

if(someCondition)
    return "foo";
return "bar";

Yes you make some valid points, but you also try to pass off your preference as best practice and give no support for it other than an insult for using said technique. You're an asshole.

And you have no sense of humor. Seriously, it's a rant, get over it, you don't know me, and we're all entitled to the occasional rant.

The only thing I disagree with you about is commenting ending braces. If you're forced to use a language that has them, i.e. not Python, Haskell, etc. , they can clarify the usual braceTrainWreck at the end of some methods, particularly if you're using anonymous inner classes. Your IDE will highlight the matching brace or the entire block, but what about the blocks within the highlighted block?

                     }
                   }
                 }
               );}
             }
    } 

etc.

clicking/cursoring up to the block you're interested is an interruption to your thinking, well, mine, anyway At least LISP/Schemers know enough to put all the closing )'s on one line.

As I said earlier, your method shouldn't be so long that a brace is opened and not closed without scrolling. Lisp and Scheme certainly do it better, but it looks better in them on one line due to their awesome syntax.

LOL! I really enjoyed this blog entry. I feel the same on most accounts. I'm definately with you in regards to breaking up long methods. So, I heard you were doing a sequel...

Regarding switch: Polymorphism is an excellent idea when the difference between each case is a different class, and representing it as such is beneficial. But, say, you're switching on a letter (keycode of a keyboard event under WinAPI). Or a string (command line arguments). And so forth. Because these are the cases I see programmers using switch statements most often simply because the alternative--if and else ifs--is infeasible (so this is me refuting the "hardly any" qualifier). Polymorphism doesn't work there.

Nice rant. Nothing gets me hotter than a pissed off software developer. If I worked with you, I would swing by your cube everyday so you could stomp all over my ego and I could stare you in the eyes and quietly tell you how much smarter you are than the other guys in the office. Then you would look at me in disgust, momentarily confused and frightened. Your lips would begin to spread and your bottom would feel slightly warm and moist. The adrenaline would consume you, and you would lurch forward and tell me to fuck off in a seething, quivering voice and I would back away cautiously, then turn and run back to my cube, where I would email my therapist and post on reddit for the rest of the day.

By the way, the 'Name' field on your comment form was populated with the previous poster's input. What's up with that?

Re: exceptions vs. error codes

Ramon, good effort, but Grandpa is unconvinced. There is no advantage here for exceptions: programmers must come up with their own exception class heirarchies just as they would error token conventions; it's a wash on that point. Exceptions certainly are more expensive, they look ugly in the code (at least in Java and C++), and they deny intermediate code that doesn't care the opportunity of continuing gracefully (the catch/throw antipattern is required).

Good night.

I don't agree with all your points, especially this single exit. As for the rest of it, your arrogant and abusive attitude doesn't score highly with me.

F - needs work

Wow. Aside from some good ideas (exceptions, & xml hell), I sure as hope to hell I am never on a project team with you. 7-10 line methods? Are you kidding? Have you ever worked on an enterprise class system? No curly braces = hard to read. Declaring variables right where you need em? That's just stupid and makes it harder to comprehend. i.e. where'd THAT variable come from??? Multiple return statements within a procedure? Thats just dangerous and easy to miss. Did you seriously JUST graduate college... err... high school? How did this make it to reddit - is this what people think makes good code?

Ramon, some great points. I agree with almost all of them.

I just hope you don't rant like this at developer's you work with =)

Getting along w/ coders on your team is like 20% coding style, 80% personality traits.

I'd MUCH rather work with a developer who occassionally (probably just b/c he's tired, or forgets) and pulls a:

if(someCondition) return true; else return false;

... than some douche who thinks he's high and mighty and the all-knowing keeper of the One True Way to Do Programming.

ps. what kind of pretentious blowhards read this blog of yours? "A coworker of mine just wrote an article about the declination of OO..."

Does he mean "decline", perhaps? =)

I may not be a developer anymore, but as a development manager for a fairly large company, I'd have to say:

Shut up. Different people have different coding styles. What works for you doesn't work for others. Your code pisses people off too. Speaking of that, how'd your last code review go, oh, and why are you writing this blog post in the middle of the day, is that why your project is 2 weeks late?

I've always hated when I see pointless nesting...

void foo(file) { if(fileexists(file)){ dosomething(file); //10 more lines } else { //handle simple case with one line } }

instead of the simpler void foo(file) { if(!fileexists(file)){ //handle simple case with one line return; } dosomething(file); //10 more lines }

especially when there is nothing in the simple case, and the entire function ends up being indented for no reason.

some good pointers, but also reminds me of an english pet peeve i have-- using ignorant instead of stupid. the two aren't interchangeable.

[@Really?] I agree in the sense that, yes, people have different styles and others need to just get over themselves in order to work together - but based entirely on this blog posting alone, it's not even remotely clear that the author works in the kind of place you seem to manage. (Or, indeed, would even want to!) He may very well be an independent contractor working from home and this code was just passed his way to "fix" by some client. Also keep in mind that "middle of the day" is someone else's "middle of the night."

In any case, I think a lot of the over-the-top language was in jest, anyway.

Depends on the code. I've worked on and written mathematical code where it makes more sense in one routine even though it spans pages. And where one line of code may have half a page of comments to explain it to future, non-domain-expert maintainers.

Similarly, if there's an "error code" that can fall through the rest of the code cleanly, then use it. Exceptions do not play well in parallel or distributed systems. See some of the recent-ish work on Haskell exceptions for elegant ways to bridge the gap.

Some problems are hard. Coding styles don't magically make them easier. Many of your suggestions do make the majority of code more tractable.

If you deal with databases, the condition could be True, False or Null. You should explicit test for == true.

If you deal with python, the condition could have been None, an empty string, an empty list. Each could have evaluated to a False. But it might be better that the function actually returns T or F.

If you are in VB6 land, condition could have been -1 (in which case it is True)

The o prefix can help identify the difference between instances and Static method calls. Especially when you are reading someone else's code.

Somebody said...

"Hungarian notation, used as you mention, is also garbage. Putting an "i" at the start of a variable because it's an integer is nearly 100% useless and distracting, and just one more thing to screw up maintenance wise down the line. Instead, the reason for the variable being an int in the first place should be in the name, such as a "Count" or "Index" suffix."

I admit that their are a few idiots who prefix every integer with "i" and call it Hungarian notation, but please judge the practice by people who know what they're doing. What those people use for prefixes are things like "cb" for count of bytes, "ix" for index, and "se" for escaped string, which seems to me to be pretty similar to your suffixes, only shorter and with more information.

Most of the article is great, except for: "To put it simply, use the Samurai Principle, a method either succeeds, or blows up with a suitable exception. Error codes are not acceptable in a modern language, it's a dead technique."

Creating exception objects can be a serious performance penalty. If you want fast code return NULL when your method fails, have all the methods check for NULL in the return value of a called method, and check all params for NULL at the top of each method. Checking for null is, at the assembly level, one CMP for the check and one JMP for the branch and return. Generating an exception is.. ridiculous by comparison.

Some devs like to write code that rely on exceptions to handle bad user input or other errors, but I don't agree with that practice, because you have less control over the control flow of the program. It's worse than unrestrained use of GOTO. Also, in some languages you have to check for specific kinds of exceptions and possibly miss other kinds of exceptions.. bleah.

>one of the things I can't stand is when students: > >result = someOperation(); >return result; > >instead of just >return someOperation();

what if one needed to change the return type of someOperation (or it changed in an upgrade)? then i need to change the return type of this method, etc. this way the method is insulated from changes in the other methods that it may call.

A fun read... the article and comments. I found them both quite informative. I see much of this being easier to apply to Python and Ruby (Smalltalk as well of course) than Java. It seems many people apply C++ (and C) thought patterns to their Java programming.

BTW, its always good to blow off some steam sometimes. I got that right away from your tone (and your comments just clarified it). On the other hand I do sometimes enjoy the comments where people do not realize your going a bit over the top, etc. They add a little spice... but don't let them bother you.

Splitting up functions can IMO be done for three reasons: It needs to be used by something else, it has more than one purpose, or it's too long. The last one is the least important - If a long function is used by one object to do one thing, it's not getting split up unless it spans several pages (by which time it's highly unlikely to fulfill the other criteria anyway).

Actually switch-case statements are >= the State design pattern for small state machines. The reason being that if you're language doesn't support GC, then you have to go instantiate a bunch of state classes and fret about fragmenting memory, not to mention the cache coherency that goes out of the window due to virtual functions. Actually most of these pet peeves can be really good examples of code in certain circumstances. And I hate exceptions! Try-catch blocks cluttering up the code, weirdly unwinding the stack on error and extra verbiage cluttering up the language that ultimately end up confusing you. Error codes are the way forward. :)

Very nice post Ramon, again! I fully agree with all you say: single exit point, long methods, simple native types, comments, XML hell, everything is right on the point of most of java/c++/c# applications I can see.

Your blog is my top favorite those days. Keep on going! :-)

You writing style is rude and obnoxious. Some of your arguments are weak, or about trivial points. I get the impression that you do not work well with others.

I'm sorry that I wasted my time reading your post.

Ignoring the very silly (and typical) arguments in the comments (and taking on board this is 'personal pet peeves'), I thought this was an nice post, can't help but agree with you on most of the points.

People not understanding the nature of booleans (and assignment) is probably my biggest pet peeve as I have to deal with people doing it on a daily basis.

I'll be keeping an eye out for some interesting smalltalk posts in the future.

You must work as a sole developer reading over amateur code for those to be your pet peeves. I work as a senior member on a team with over 50 very smart programmers and I can tell you don't know anything about writing solid code just from this post. You might be smarter than the average php or visual basic web developer but you think you can speak with any authority about real world development practices. I'd love to see you revisit your opinion in a few years.

I disagree on the point about error codes, but only because Exceptions still do not have first class status in most languages today.

> try-catch blocks cannot be inserted into expressions > catching can only be done on types known at compile time > exceptions can only be grouped via the object hierarchy

On the other hand: > well chosen sentinel values can be quietly passed around by functions that ought to ignore them, preventing premature leaps up the stack in non-critical situations > a caller doesn't need to contain within itself the error codes it is responsible for handling - it can read them from elsewhere > By "||"ing or "&&"ing or otherwise aggregating error codes, a caller can have the same code be run for different error responses, even if those responses are not necessarily related in the hierarchy

Of course, error codes still have their own problems - namely that there is no language wide consistency, and most languages don't provide contracts powerful enough for requiring callers to be aware of them. On the other hand, C# completely ignores exceptions as contracts.

While I think bringing error handling into the type system is a good idea (for correctness purposes) in principle, I think most languages have failed at this goal. Java made the mistake of making exception throwing explicit, and C# made the mistake of making exception handling optional. The correct solution would have been inferred throws and required handling. But even with that, there are still so many improvements to be made. (Compare to CLOS's exception handling, or even Haskell's.)

From the post, its pretty obvious that you have very little coding experience working with a huge team.

It's also pretty obvious you have very little coding experience in PIC or other HW chips.

This article was fantastic. I am more than a bit disappointed by the comments posted. I programmed in VA Smalltalk for over three years with a team of around 100 other good Smalltalk programmers.

I believe that once you have experience in Smalltalk, avoiding the listed pet peeves comes naturally. Being immersed in a completely OO world without primitives and non-object class definitions makes you think in terms of Objects. The Smalltalk IDE's I have worked on which are method-at-a-time, promote small methods. The simple syntax really allows a programmer to create fully descriptive method and variable names.

I am happy to see that Smalltalk experience has provided someone else with good programming practices. Again, I am disappointed by the negative comments, but I can chalk that up to ignorant people without any relevant Smalltalk experience.

I'm disappointed by the amount of people that apparently have no sense of humor and can't tell I was blowing off a little steam and going over the top on purpose. Seriously people, read the rest of the blog, this isn't my typical writing style at all, it was in jest.

The number of commenters that took this post personally is amazing. A couple of points are stylistic choices. Most of the others show that people don't understand the language itself.

try-catch exception handling is just another term for "goto." That it's in vogue currently doesn't change that it's an uncontrolled program logic jump.

Your comments apply primarily to heavily OO languages. They cannot be applied to all situations, especially if you're dealing with anything low-level.

Stop thinking like a software engineer and think like an actual engineer. Use the right tool for a given job.

Illustration: http://philip.greenspun.com/humor/eecs-difference-explained

You make a couple of good points, but there is no need to be so damn caustic about it

Ramon,

You're having a lot of difficulty with this post on the basis of your tone. You refer to everyone as "people" -- as in "seriously people" and "get with the decade people" -- and its off-putting. People don't read your blog to be lectured like children or to come to the altar of your great wisdom so they can prostrate themselves before your superior intellect.

You ask for tolerance in reading the post, but your post is about a lack of tolerance in reading other people's code. Yes, I realize it can be frustrating to see things that annoy you over and again. But you should take the opportunity to share insights with people who come to your blog with a collaborative frame of mind, rather than bonk people over the head because there are too many "else" statements.

Let's face it -- this stuff is comparatively minor. Last week I had to completely rewrite an ecommerce app because some guy had created two tables for purchase information, both of which stored the exact same data but weren't linked in any way whatsoever and -- oh, the list goes on. Believe me -- BELIEVE ME -- I WISH that the biggest problem had been a profusion of comments.

Yeah, yeah -- you were blowing off steam. Fair enough, except no one here had done anything to make you boil. Relax. Enjoy life.

Ramon, When reading these comments please don't forget that the tiny antisocial minority is much more likely to post than the appreciative masses.

Anyone: Does this phenomenon have a name? Thanks.

Believe me, I could care less about the comments, and I'm one of the most relaxed easy to work with guys most people would ever meet.

Anyone who thinks otherwise, go read the rest of the blog, this is one silly little post where I blew off a little steam after digging through some crappy code for 3 hours, it's not big deal. I can't help it some people don't share my sense of humor, oh well, that's life, but it's no skin off my back.

Very much like the suggestions out of "Writing Solid Code".

Other people use silly standards when compared to my world beating personal standards that only I use. I am the King of code. I am the yardstick by which I am measured. I spend days writing articles showing people their wrongs in an effort to put things right for a brighter day for you and me. I spell like a child because I spend all my time noting peoples coding errors. You may think this blog is offensive but I dont care. I have the demeanor or a Saint and the humour of Bill Hicks. Thats doesnt make me a bad person but rather a genious. This paragraph is nearly over my self imposed limit. I therefore will start a new one.

I am the coding king. You are not. Adieu

Ramon, You are an idiot and here is why.

Your example about "Single exit points". You say this is bad:

string result = "";
if(someCondition)
   result = "foo";
else result = "bar";
return result;

You suggest this instead:

if(someCondition)
    return "foo";
return "bar";

FYI - code should be self documenting, having an else is good practice - go read a javadoc you idiot! - this is very common knowlege so you are an idiot.

ALSO!

You say, "Stop prefixing your damn code with type declarations. " You know what, I like knowing it's my variable is string or a double. So STFU!

Poor, hourly paid employees like you always bytch!

Stop bytching and blaming - loosers like you do that a lot - so cut it out or I'll outsource your job to Russia!

Go read "Code complete 2nd ed." by Steve McConnell (http://www.cc2e.com/) where the above points are mentioned but in a more detailed and less 'rude' way ;)

Dan: Just tried this in VS.Net and it works - if(someCondition()) return "foo"; else return "bar";

I agree with many of the points you list, but I personally hate the "modularize EVERYTHING" method of coding. Reminds me of one time where myself and another developer had to debug a minor error in a project the day before a demo. I had inherited this project, and at that point it was pretty much full-on spaghetti. The error ended up being found in a function about 10 levels down from where you'd expect it. It was on the order of "A() calls B() calls C() calls D() calls E() ... called Z()" which is where the problem was. Most of the functions had a very specific use, were only called by the function above it (and often private), and were pretty much had no point other than to keep methods short. I had to start taking notes on what called what because I was flipping around the code so much. It was a real bitch to debug for such a simple error. But hey, at least the functions weren't too long.

I realize you admit there are exceptions to rules, but I think methods should be split up only when there is a good reason, and I don't think "longer than 10 lines" is such a reason (longer than 50 might be, though). That is one of MY pet peeves. :)

As for most of those commenting here: I do have experience in multiple languages on multiple platforms in teams both large and small at multiple sites and have had to maintain/maintain the code of others. What Ramon is saying rings true and not following it has caused me grief countless times. Of course this applies to coding "business applications" with modern OO languages, not embedded systems with things like C.

I do however like the extra braces even though they are not needed.

In my previous comment I meant maintained/enhanced

Paul, Using a good IDE helps mitigate this issue. Also, it seems developers only follow part of the rules or they don't follow them correctly which probably what is causing your problems. Bet there are little or no unit tests either.

Seems people misinterpret writing small functions as nothing more than breaking up larger ones. This however, leads to long chains of dependent calls as Paul said, A calls B calls C.

You don't break up large functions into small ones, you simply never write large ones. The code patterns are much different, you don't end up with long chains of dependent calls.

If you write a function with only one purpose in mind, from the bottom up, not from the top down, you simply end up with small reusable functions.

Those who are complaining about breaking out chunks into separate functions are writing top down, not bottom up, which explains why they can't see the value in doing this.

Use a class for each case??? You, sir, are a moron.

Great post Ramon! A rant is a great way to get lots of feedback (even if a lot of it is angry). Oh well, brought me a smile.

Hmm. That wasn't from me. Another Mark perhaps?

i think i may still be quite inexperienced.. i do, at times, refactor code.. but why waste time refactoring IF it is of absolutely no benefit to me?

Hungarian Notation is the worst of all. My (no longer) boss once wanted us to prefix all PHP arrays with "arr". I considered naming variables $arrMatey.

Jerk is funny...mostly because his example shows how poor a coder he is. For example, I just love this: string result = "";

Apparently he never heard of null. Also, the entire method, as someone else already pointed out, could just be:

return someCondition ? "foo" : "bar";

Javadoc? Oh that explains it.

Great post. Too bad a lot of the commenters are so touchy about your tone. Having recently cleaned up some garbage code myself, I was right there with you. It's not so much about agreeing with every little detail, there's always room for some differences among coding styles but it's about clarity, conciseness, and consistency. No need to make a simple conditional return take up five lines when a one-liner will do - especially if clarity is improved. Consistency is the one that really gets on my nerves. I saw some code recently where the author couldn't decide if he liked method names likeThis() or like_this(). The truth is you can often gauge experience by aesthetics.

By the way, before I get flamed, the Javadoc comment was a joke :)

Christian, you've got it exactly. There's always room for different opinions, but clarity, conciseness, and consistency are huge and often ignored. I would type

return someCondition ? "foo" : "bar";

myself, but I was referring to the patterns in larger pieces of code, not just a single simple condition, else I'd have done that too.

what should have (justifiably) motivated the old programmer to write more aesthetic code? this is what i don't get..

Grokking booleans:

if(someCondition) return true; else return false;

Is often better than the suggested "return someConditon" on grounds of improved maintainability. OK, so someCondition is a boolean now; but in the future its type may change. So changing "if(comeCondition)" too "if(comeCondition == someTest)" is a simple change (one lines needs changing). But if you started with "return someCondition", and someConditon changed type later, then you'd have to write the four lines. In a dynamically-typed language, returning someConditon culd lead to a bug when it changes from being a boolean to something else and no compiler gets to do type checking for you.

The original code might be longer, but it clearly states the purpose of the function and defends against future changes.

Single exit points:

Single exit points are, in general, much better than multiple exit points! The reason I say this is that it is orders of magnitude easier to perform code coverage analysis on functions that have a single exit point. I once worked on a project that required something like 98% code coverage, and we quickly learned that single exit points make achieving this much easier (possible, even). They also make the code easier to read, because you know where execution starts, and where it ends.

The algorithmic complexity does not have to increase; many languages feature a "break" keyword to jump you out of the loop (and you can usually easily arrange this to get you to the exit point). Once a compiler has processed the code, in the worst case a break will add the equivalent of a jump instruction, and at best will be directly equivalent to your hand-coded immediate exit point.

Using single exit points is likely to make code shorter, easier to understand, improve algorithmic elegance and be easier to test with code coverage tools.

Too many comments:

This is a matter for coding conventions or personal taste. However, if comments describe what the code does (and aren't left to go stale), then they can significantly help a maintainer understand what the code does and how. In my opinion, we should be producing so called 'literate programs'; it may seem clever to you to write code that only you can understand to massage your ego, but given that code is written once and read many times, the more help you can give your audience, the better. I for one don't want to be made to feel stupid because I can't understand how a program works simply because the author didn't want me to. Especially ones with all those exit points :-)

Factoring code to reduce its complexity to a level where understanding it is trivial is, in general, sound advice. However this is often not possible in certain problem domains, due to performance requirements. In scientific numerical programming (and presumably also 3D graphics and the like), code really can't run fast enough. In these domains, the cost of many function calls can really hurt you. Functions can get too long for comfort in order to hit the performance targets. In this kind of code, lots of reassuring comments go a long way to helping maintainers understand what the code does and how.

Switch statements:

Not all programming problems are suited to object oriented programming. In these languages, switch statements are much better than a big if statement.

doing

if (someCondition == true)

can actually be detrimental to readability in a case like this: if (weFoundAnError() == true)

it makes your brain have to think about what is happening inside weFoundAnError() that would make it return true, and also the concepts of "error" and "true" fight each other, whereas you could have read it in plain english like this:

if (weFoundAnError()) handleError()

Microserf, you're setting up straw man arguments and knocking them down. The only valid response in your entire reply was...

"Not all programming problems are suited to object oriented programming. In these languages, switch statements are much better than a big if statement."

To which I agree, but again... This is a Smalltalk blog and a post about C#/Java/VB, so obviously I'm referring to object oriented languages.

OldTimer and radman, I'm not trying to convince anyone of anything, this isn't a post that argues for my style, it's simply a statement of my style.

If you want arguments for said style, go read some Martin Fowler, Kent Beck, Eric Evans, Rob Martin, Ralph Johnson, Paul Graham, or Rebecca Wirfs-Brock, all of whom are far better advocates and writers than I and have much more to say on the topic. I'm just an ordinary programmer.

this is more curiosity than criticism.. i was just wondering what motivates some programmers here to write code that is aesthetic to others..

what is their return on that investment?

Not everyone's in it for the paycheck. Some people, myself included, actually care what code looks like, beyond its intended function. To me, it matters if I can delete half a function without actually changing what it does.

It matters because IMHO, simpler code is easier to maintain, and over the years, I've been bitten far too often by code that was just hacked out quickly to get a job done.

I do my best to no long write code I'm not proud of, for any reason. I'd rather do something right, once, than half ass it, and have to come back several times to fix bugs created by my rushing to meet some artificial deadline.

I left the corporate world because of such deadlines, now I do things right, and it's done when it's done and no sooner. It's a craft, and I won't rush it for any reason.

i agree with you.. it sounds like you have the ideal position.. my assumption is that you don't share your finished code with 3rd parties though.. or do you?

what position are u in btw? consultant? academic?

I suggest including braces in if statements that only execute a single line of code. You never know when you or someone else will need to extend that part of the code. If the braces are there to begin with, nobody has to remember to add them.

That, and it just looks consistent.

Neither, I just moved to a small company that's decided doing things right works better than doing them fast. The only code I can share, is what I share on this blog, as part of my hobby coding on the side. Work code obviously doesn't belong to me and can't be shared.

I disagree on the braces, because I find I have more one liners than multi liners, and our IDEs auto format so you can't mistakenly forget them. I tend to separate what happens from when it happens, so my "if"s tend to call methods, not so much contain a bunch of code.

I don't do this...

if(someCondition){
   //bunch of code
   //bunch of code
   //bunch of code
   //bunch of code
   //bunch of code
   //bunch of code
   //bunch of code
   //bunch of code
}

I do this...

void someMethod(){
    if(!someCondition) return;
    //bunch of code
    //bunch of code
    //bunch of code
    //bunch of code
    //bunch of code
    //bunch of code
    //bunch of code
    //bunch of code
}

or this...

void someMainMethod(){
    if(someCondition)
        someMethod();
    else someOtherMethod();
}

void someMethod(){
    //bunch of code
    //bunch of code
    //bunch of code
    //bunch of code
    //bunch of code
    //bunch of code
    //bunch of code
    //bunch of code
}

Preferring to keep methods short and readable like English, the method name serves as the comment for that chunk of code.

[...] I saw this article on coding pet peeves and generally agreed with most of it. I don’t get peeved if stuff happens but my style mostly matches the guy’s preferences. I depart in a few key places, though. Problem: Single exit points - Sure, it’s easy to complain about single exit points but they’re a boon for a lot of programmers. The author says “we have garbage collection”, but, for many programmers, there is no garbage collection. Objective-C will eventually get GC but it doesn’t have it yet. Many times, having a single exit point allows me to make sure everything is cleaned up. [...]

you are so spot on. i too am becoming disillusioned at the idea of ever surrounding myself with quality coders in a corporate environment.

Good post. And it was great bait to lure out the crappy programmers. Do you log IP addresses so we can point out to their firms?

One guy goes into detail about how much computation the CPU must do to handle exceptions. You realize we are talking about exceptions right? Do you really care how efficient the code is as it's crashing? Now people who use exceptions like goto's should be shot.

Another guy says all variables should be at the top of the function because otherwise they jump out from no where! Some how it has escaped his notice that probably 90% of his variables at the top of the function don't get initialized for most of it. Some may never get initialized at all. The whole point of putting the variables in the scope they belong too (e.g. if you use a c++ for loop make the iterator right in the for loop like for(int i =..) so it doesn't leak all over) is so you don't have to remember all these variables that probably don't even get used. If this is too hard for you then pick another profession.

As far as the switch statement bit: it is a question of where do you want to branch. Let's take a regular expression for example. You can do a quick parse over the regex and build a basic structure and then in your matching code you have a big nasty switch statement. This is ok if you don't run the parsing code much. But if you are going to parse a lot of strings many times, it is better to use objects to represent the expression so you do the branching at compile time (of the expression) instead of every single match attempt.

I enjoyed this a great deal. (And the comments are priceless. Apparently there's a mob out there who can't understand context -- or read preambles -- at all).

Good work. Here's another vote for a sequel.

"Switch Statements Stop using them, period. There's hardly any cases where polymorphism isn't more appropriate. " "Declaring variables at the top of a method In languages that allow it, you should always declare your variables and initialize them in the exact spot you want to use them. " What a bunch of crap. You are a sociopath that writes code in isolation and never is part of a team, esp a team that contains junior programmers and a team where readablity is a concern.

Good article. However I disagree partly on your idea on XML. Some programs can be build around XML if they have few business rules. You don't have to always use the object paradigm if you don't need to.

microserf: The boolean argument is pure nonsense. If code needs to change, change it. The multiple return argument is difficult to defend too. Go skim Refactoring: Improving the design of existing code by Marting Fowler and look at guard clauses. Try it on real code you'll be surprised how much readability is improved. Also, all but the most naive tools can handle this pattern with ease in 2006. Any tool that can't is not worth running against my code.

The problem with exceptions....

Is that they're just plain half-assed. They do one-half to two-thirds of what they should do.

I don't really know enough about Smalltalk to know if smalltalk's exceptions are better than the average, but: One language gets exception-like functionality right, and that is Common Lisp with its Condition system (to be fair, many scheme implementations have conditions too, but they're not "standard").

Conditions are Exceptions done right.

http://www.gigamonkeys.com/book/beyond-exception-handling-conditions-and-restarts.html

Basically, while in most languages, you through exceptions and handle them, in lisp you signal conditions, offer restarts, and the handler can choose to change something and restart from where the condition was signalled. This leads to a much more natural and expressive control flow.

Jim, Sorry, but Ramon IS concerned about readability. Especially in a team of juniors. I suggest that if his code is difficult for you (or juniors) to read:

Get a better programming language. Get a better IDE. Get a different job.

A. nonymous gets it right. The problem most of these people have with exceptions is that they have only seen the broken C++ version of them (for those who don't know: that's what Java uses as well).

In the Smalltalk and Lisp family exceptions are a whole other animal. Although at this point I think Lisp has the best. Lisp exceptions are based on the understanding that the lower level function knows what happens, and knows what different things could be done, it just doesn't have enough information to decide which strategy to use. So the higher level code that does know can tell it. At compile time.

It's interesting to note that Hungarian Notation, as originally devised, was not the perverse pit of despair it is today. Once upon a time, those little prefixes provided actually useful information. 'xScreen' is an x-coordinate on the screen, 'ydWindow' is a difference of y-coordinates (more commonly known as the height) of a window, 'iPerson' is an index into the People collection, 'cThreads' is the total number (or count) of threads.

This is terrifically useful information, and a convention for adding such information in a concise manner is a very good thing. Joel Spolsky talks about this: . Interesting read.

That said, I completely agree that the more widely known Systems Hungarian is an abomination unto God. May it be purged from collective consciousness of the coding masses. Amen.

Er, Joel's article is here: http://www.joelonsoftware.com/articles/Wrong.html

I'm not a big fan of Mr Spolsky, IMHO, a much better business man than programmer. His well known stances against exceptions and extreme programming mark him an old dog in my book.

As for Hungarian Notation, even done properly, I hate it, I'll take height, count, and index over ydWindow, cThreads, iPerson any day.

Variable names shouldn't require me to have memorized a system of prefixes, ever. They should simply state what they are, in plain English, with no abbreviations or weird codes. There's not a shortage of words in the world, abbreviations are unnecessary.

Ramon - Amen, brotha. Smalltalk With Style rocks.

After I read your post, I was mostly in agreement with you. I was a little surprised when I got down to the comments, though. There's no need to get your panties in a bunch over this. ;-)

No idea what you're referring to.

In the past I've done some of the things you describe. Some of what you talk about sounds like people coming from VB, and just don't understand that you can say things more tersely. In other cases it sounds like people coming from a C/C++ background. Some of them sound like newbie mistakes.

As a C developer I used to do:

if(func1() > 0 && someVar1 != 0 && func2() != 0 || someVar2

just to make it clearer. For me it helped because of consistency. Every test was of the form: opand1 op opand2. I agree for the one term tests, testing for "true" or "false" was unnecessary.

I'm embarrased to say that when I was first learning C# I failed to grok assignments sometimes. I did just what you described. (blush) I think it has more to do with misunderstanding how the whole referencing system works. I came to it from C++. In that language it's possible to assign one object to another one, doing a shallow or deep copy. I probably figured I needed to "populate an object" (the ArrayList referenced by someItems) in some cases, rather than just receive an object from BuildSomeList().

As for your "single exit points" example, what irritates you has been promoted by "best practices" advocates. I think even "Code Complete" talks about doing this. Probably what this technique was meant to address was keeping track of state inside functions that are tens or a hundred lines long. In that case I can see value in having a single exit point, because otherwise it would be difficult to find all of them. In short functions, though, I agree it's more clumsy than necessary.

I don't comment closing tags anymore, but as a C/C++ developer I used to, just because some functions would get long, and it was maddening trying to figure out what closing brace went to which opening one.

In Smalltalk it makes sense to have short methods. There's no private or public distinction with them, so what's the point in making them long, right? In other languages breaking a large method up into a bunch of methods can make sense, but I don't see the point if the code, though it be large, is really intended for one specific task. If the code is logically tightly coupled anyway, what's the point in creating a bunch of private methods that only one main method will use?

I think what you're really getting at with some of your comments is more of a design issue. What I see you saying is "Use a DSL!" It makes more sense in that context. Unfortunately most programmers are not taught about domain specific languages. I wasn't when I was in college. When we learned OO it was more like "dog and wolf are a type of canine. Therefore 'canine' is the base class and 'dog' and 'wolf' are subclasses." Likewise, "Circle is a special case of an ellipse. Therefore ellipse should be the base class and circle should be the derived class." When I got into doing real projects these analogies were somewhat helpful but not great.

As for exceptions, I think what you're getting at is the classical exception principle: If you merely want to send a signal back to a caller then use a standard error/status code. If something happens that is unexpected, throw an exception. For example, if you have a class with a list, and you implement a method that finds something in it, it doesn't make sense to exception out if the function can't find a value, because that can happen with a list search function. Just return -1, null, or nil, depending on the language and the context. But if another object is using this class, and it has an algorithm that assumes that every value it searches for will be found, then if it can't find a value it needs, it should be the one to throw an exception.

There are other considerations as well. In .Net, for example, they discourage programmers from using exceptions that much, because they're expensive. They apparently slow down performance quite a bit if they're hit a lot.

Re. use a consistent style. Wholeheartedly agree there.

Re. XML, I agree with you. Use it strictly as a data transport medium. What makes me cringe is I've heard of people using XML files as databases. Yuck! IMO that's as bad as using an Excel spreadsheet as a database.

All good points and much of what I'm saying does come down to design issues. For example, breaking up large methods into a bunch of smaller private helper functions. Well, that's not what I'd do, because I think it stinks of bad design.

First, I wouldn't write long functions to being with, secondly, if you have one main function and a lot of private helpers, I'd say you have an object hidden there that you should extract into its own class, and make all those helpers public. You'll end up with more classes, all containing vastly simpler code, with mostly public methods, a much better design. Smalltalk has no concept of private, public or protected methods and IMHO is far superior to "any" other OO language in common use.

Long methods, carry with them, all kinds of bad practices meant to cope with the length of the method, things like single exit points, declaring variables at the top, reusing variables many times, not using guard clauses, deeply nested conditional structures, etc. Stop writing long methods, and most of these other practices no longer make sense.

You don't write long methods and then break them up because you want parts to be reusable, that's the wrong approach. The right approach is to write single purpose short methods that are either one of two things, an implementation of a single concept, or a sort of manager method that consists of nothing but calls to other methods with workflow and conditionals deciding what to call.

Short methods are composeable, so reuse is a side effect of good design, it's not the goal. You don't build a brick house by pouring it as one solid concrete block and then cutting it up into bricks, rather, you build a bunch of bricks, and then slowly build up the house from them. This is the top down vs bottom up approach to programming.

I'm of the Smalltalk/Lisp mindset that the bottom up approach is the superior approach to programming, and of the mindset that part of doing so involves bending the language to better suit the problem at hand, by creating an embedded DSL to express those solutions in. This goes against what most "popular" languages promote as best practices, probably because most of them can't do it. Oh well. I'll work with the tools that work best, not the ones that are the most popular.

Meant to say:

As a C developer I used to do:

if(func1() > 0 && someVar1 != 0 && func2() != 0 || someVar2 < 2)

Re: "I'm of the Smalltalk/Lisp mindset that the bottom up approach is the superior approach to programming, and of the mindset that part of doing so involves bending the language to better suit the problem at hand, by creating an embedded DSL to express those solutions in. This goes against what most "popular" languages promote as best practices, probably because most of them can't do it. Oh well. I'll work with the tools that work best, not the ones that are the most popular."

This is what I'm working towards. For several months I've been drawn to learning Lisp and Smalltalk. It began when I was introduced to Dr. Edsgar Dijkstra's philosophy that the computer should enable the programmer to express his/her idea to it, and it should in effect "figure out the rest". This was not the mode of instruction I got when I was taking computer science. I wrote about this in my blog at http://tekkie.wordpress.com/2006/05/31/rediscovering-dr-dijkstra-and-giving-lisp-a-second-chance/.

I wasn't able to put my finger on why I was drawn to this concept of using expressive languages until I saw your post on Martin Fowler's presentation of DSLs. You linked to his presentation video, and it was very enlightening.

I went into this with some skepticism, because I was thinking that he was going to talk about how to create interpreters or compilers that would deal with a DSL. Fowler said a DSL could take any number of forms. He illustrated how it could be implemented in Ruby, which closely modeled the DSL he wanted to create. Interestingly he didn't give Smalltalk or Lisp examples. He also showed how it could be used in Java. The Java code didn't look much like a language (speaking of a DSL), but I think what he meant was there was enough class infrastructure created, using this method, such that you were programming totally with domain-specific objects to solve the problem, not primitives, like what you were criticizing. So even though Java, C#, etc. don't allow you to create elegant DSL solutions, programmers can still use the technique in those languages to improve their code.

It took me back to an article I had read about 3 years ago, about some work that Charles Simonyi was doing in this area, using .Net. The idea he has is to let domain experts model a system, using something similar to Rational Rose (just using it as a rough example), and then have the software create the DSL which the app. developers would use for constructing the app., filling in the model with logic. Simonyi didn't call it a DSL, but rather an "application-specific API", but I know this is what he was talking about. The concept maps directly. It was hard for me to wrap my head around it at first. It sounded like a novel concept to me, but I had the feeling he was on the right track. The problem Simonyi is trying to solve is the complaint from customers that they tell the development team what they want, but it gets "lost in translation". What they end up with is nothing like what the customer asked for. I've heard of this happening, and I don't know how it does. I've never been on a team or in a situation where we've produced something that's so off base the customer doesn't even recognize it. Every project I've been on has ended up being at least close to what they want, without needing the help of a tool to get that communication across. Nevertheless I'm glad for Simonyi's effort, because the failure rate of software projects is deplorable. It gives people in my profession a bad name. If he can work out a solution that will significantly decrease the failure rate, then I'm happy for it.

Simonyi invented Hungarian notation at Microsoft, by the way, so I imagine you hate him. :)

As for me, I'm just trying to improve my skill and try to get back to something I lost: a time when programming was challenging and fun. Not to say that I haven't had good programming experiences, but it's been diminished by experiences of frustration: "Why is this so complicated?" Before I got into college programming used to be simple. You'd focus more on the problem, and get headaches trying to solve the really hard ones, rather than trying to wrestle with the plumbing or the language. That's the way it should be.

What I've been realizing, largely by reading some of your posts, is that learning how to create DSLs is crucial to creating an elegant OO solution. I hadn't realized that before. I saw your post on Albatross, and was blown away. I could tell it made good use of the DSL concept, and it's wonderful!

Mark,

I encourage you to read Eric Evans book "Domain Driven Design" which propose an approach to distil your application toward something which help kind of "embedded DSL" emerge. As for Fowler, his examples are in Java but he is actually coming from Smalltalk.

The main problem I see today with "DSL" in their name.

The word "Language" has a lot of different meaning for computer people and it is easy during a discussion to have the feeling people are talking of the same thing, and actually, they are not. Lot of my colleagues understand DSL as a mean of creating new real languages, such as SQL, AWK or maybe XML. They are seeking to improve the design by adding full languages in their java/.net application. The result is one more heterogeneous module, appending to the list of SQL, XML, HTML and the like. More complexity and more failures.

Fowler wrote that is never felt the need to create such "full language" with Smalltalk. It is one of the things I like very much with Smalltalk: you really don't need all this accidental complexity of external micro-languages.

:-)

I second that, Evans is great and Domain Driven Design is on my recommended reading list already.

"accidental complexity of external micro-languages"

I like that, it sums up nicely what I don't like about C#, Java, and VB.

Just look at the proliferation of XML micro-languages like Ant people use when working in these languages and you'll see that when you don't have a flexible language like Smalltalk, Lisp, or Ruby, you start faking it with XML.

"Just look at the proliferation of XML micro-languages like Ant people use when working in these languages and you'll see that when you don't have a flexible language like Smalltalk, Lisp, or Ruby, you start faking it with XML."

JRuby and Groovy are helping to fill that whole on the Java side.

What I dont like with JRuby and Groovy is that instead of having Java-only, Ruby-only or Groovy-only, you hava java+ruby or java+groovy. Java is a over-complex system by itself, and adding one more layer on top of it does not really help to lower the complexity. This is one more micro-langage appended to the list.

However, maybe in 5 or 10 years, after playing a while with JRuby and Groovy, it might be that java and those dynamic langages could merge. Fine. As I have complex business problems to solve now, I have no time to wait the mainstream to lower its accidental technical complexity and I prefer to go directly to the best available: Smalltalk.

Exactly, Smalltalk is available now, and it has the best development environment in existence today. Nothing else even comes close IMHO, not even Lisp.

I enjoyed this post a lot. I'm glad I found this blog :)

[...] My Personal Pet Peeves I See in Other People's Code | On Smalltalk (tags: programming code style) [...]

Sadly, Smalltalk is not a choice (for one reason or more) for most of us so we have to make do with what we can use.

On the other hand, you can do JRuby and Groovy by themselves. They run in the JVM but are not a layer on top.

As for Java being over-complex ... well Java in and of itself is not. Some of the technologies involved are. So if you have simple problem, use the simple stuff.

"As for Java being over-complex well Java in and of itself is not".

Any Smalltalk programmer would disagree, Java has fifty or so reserved words in comparison to Smalltalk's five. And for all those extra reserved words, you get a less capable language riddled with accidental complexities. There's nothing simple about Java, unless you just came from C or C++.

Well, when you compare Java to Smalltalk, what can I say. From an architectual standpoint, it looks bad. I guess the best thing to do is show people C/C++ and not Smalltalk. That way they won't know how bad they have it. :)

Your article is drivel. The responses are a terrific, hilarious ride.

Thanks folks!

To Mark:

I take your comment as tongue in cheek. I hope students are exposed to Smalltalk. I was when I was in college, though I had to take an elective senior-level course in programming languages to be exposed to it, and it was brief. We covered ICON, and SML (predecessor to OCaml) also.

Of all the languages I was introduced to back then, Smalltalk was my favorite. C came in second, followed by SML. I've since come to appreciate Lisp, but back then I had a terrible introduction to it, and ended up hating it.

I've talked about this elsewhere. Back then, in the late 1980s, and 1990-1992 it was common to see want ads for Smalltalk developers. But by 1993 Smalltalk had almost disappeared from the want ads. I was sad to see that happen. I did what I could to make money. I programmed in C, which was the hot language du jour.

In terms of marketable language skills today, I wouldn't wish C/C++ on today's students, in terms of what languages to learn to get a job, unless they wanted to work in embedded systems. I'd teach them Java or .Net.

If I wanted to teach them what they can achieve with powerful languages, I'd teach them Lisp/Scheme and/or Smalltalk/Ruby. Ruby actually has the potential to be a hot language in the U.S. someday, largely because of Rails and the marketing effort behind it. It would be an improvement in development technology, if nothing else.

You are a nasty little loser with a very big chip on your shoulder for a junior developer.

lol, I guess we all know what your code looks like, not so spiffy I guess.

To Mark M: Yes, definitely tongue in cheek. When I look for developers to work with or for or to hire - I look for Smalltalkers.

I would say lisp has more "out of the box" power in the language (macros are easier to do, that's about it really), but for me smalltalk is much MUCH better organized and the environment is just a no brainer.

To the person who said Java isn't complicated, it isn't if the path you take is through the languages that make a big distinction between statement and expression (c/c++/java/etc. etc.).

But Lisp, Smalltalk, Ocaml, Haskell, etc. all have vastly simpler syntax and a great deal more power. If any of these languages caught up to perl with number of available libraries then any company that used one of these would destroy everyone who didn't. We see this occur already today, but only in isolated cases (Paul Graham, Raw Dog development, etc.).

The only question is: Which will come first? Will the script/c-derived languages converge on the simplicity (unlikely, so far they add the features of lisp/smalltalk with new syntax) or will one of the above languages reach critical mass allowing people who know about to start dominating the market to a point that they can't be bought and reprogrammed in Java?

Jason,

Your question is very interesting. I understand that this question make sense in a context where it is important to use a mainstream langage with "critical mass" and "dominating the market".

Put in other words, this would be a context where it is more valuable to be in the mainstream than to use the langages you talk about (Lisp, Smalltalk, etc..).

Are we currently living in such a context? If it is the case, can we change this context or escape it?

For instance, I have the feeling that Ramon choosed to go in a context where value of choosing better tools is higher than being in the mainstream. Can we follow his examples?

To Jason and Bernard:

I think one answer is to deal with the prevailing mentality in schools, at least in the U.S., both public schools and universities. Dr. Dijkstra was complaining about this years ago, though back then people had a good excuse to dismiss him--dynamic languages tended to run noticeably slower than compiled languages. They taxed the hardware of the time. Processors have gotten fast enough, and computers have enough memory now where dynamic languages can run reasonably fast, and can be considered for serious applications. This goes in favor of Java and .Net as well. However Java and .Net were created as "the next step" for the compiled language environment. Smalltalk is a compiled language as well, but because of its late-bound nature it's much closer to languages like Lisp or Ruby than to Java or .Net in terms of the kind of dynamism it allows.

So long as people are trained primarily in the compiled languages, then the dynamic languages will continue to play 2nd fiddle to them. You can see this with what happened to ViaWeb, Paul Graham's successful Lisp project that became Yahoo Store. A few years after Yahoo bought it, they converted most of it to C++ and Perl...conforming to Phil Greenspun's Tenth Rule. The reason they gave was they couldn't find enough Lisp programmers to maintain it. There's got to be a growing population of skilled people in order for a technology to gain momentum, though this is a "chicken and egg" problem. A possibility is maybe Seaside will provide a rebirth for Smalltalk adoption, and Ruby on Rails will help people discover Seaside. The only reason I say so is that Smalltalk and Ruby share some properties, and so when people go to find out about it, they'll find out about Smalltalk as well. I think the presentation videos on Squeak (eToys) and Seaside help draw people in as well.

Ruby on Rails has more polish than Seaside in terms of presentation and access to resources for newbies. That's something that needs to be improved. I've done what I can so far to encourage people to check it out. Ramon has done a good deal as well.

Bernard: We are only living in such a context in that good programmers are being wasted in Java, instead of helping us make useful languages like Smalltalk better (and there is much to do!). So from my perspective there are only two problems with where smalltalk is today: 1) We don't get some things as fast as a mainstream language because we don't have the resources to get it. 2) If our total mass gets small enough then the language itself will stop getting developed and die (neither smalltalk nor lisp are in this situation at the moment, but I think self probably is and that is a shame).

As far as what can we do about it, yes Ramon is doing a good thing getting the word out. I use smalltalk in my free time almost exclusively (also do some haskell and ocaml).

Mark: The state you mentioned about Paul Graham can be seen as a bad thing, but it can also be seen as a good thing. The good thing is, small companies have a chance and will continue to have. In the case you mentioned, as well as the Raw Dog, a small company made a product and the larger companies couldn't keep up. So the larger company buys the smaller company, but can't use their secret weapon. So the another small company can do the exact same thing again.

Jason:

When I wrote that Lisp tends to get pushed aside, I neglected to consider the fact that many airline reservation sites (Orbitz being the most prominent) are written partly in Lisp, and continue to be maintained in it. Paul Graham has pointed this out. It's nice to know that Lisp is surviving somewhere in the real world. I guess the real story is Yahoo didn't know how to recruit and retain Lisp developers. The airline reservation services apparently do.

[...] – Ramon Leon [...]

ArrayList someItems = BuildSomeList();

I'm sorry but the above could potentially set someItems to null and cause some sort of null pointer exception when trying to use the object later.

I see it happen all the time.

Er. Yeah I put my foot in my mouth there. What I see all the time is a little different than your example... so I take that back :)

I wrote something similar to what you have here while I worked at Sun and was doing a lot of C. I just revived it and put it in my blog. Took me hours getting the formatting right so that Blogger would accept it:

http://mgrant0.blogspot.com/2007/02/mikes-programming-peeves-or-growing.html

I'd like to see more programmer blogs doing this. It's fascinating reading other peoples opinions of how code should look, whether I agree or not, I like seeing justifications for certain practices. Reading another persons code is like looking into their mind, you can tell quite a lot about a person from their code.

Sounds like some of the programmers who are ticking you off have been using Proce55ing.

Well here is an interesting blog entry finally. Personally, I quite like the tone of the article - to me it was hillarious.... "blindingly obvious" - is that trademarked? Let's see how quickly I can use it in discourse with my fellow colleagues.

some of my pet peeves...

1) Unnecessary (and sporadic) use of this: this.foo(); this.bar();

rather than: foo(); bar();

clearly the coder was hunting for methods using the IDE assist, and didn't take the time to cleanup the code. silly fool.

1. Unnecessary declaration of locals: SomeClass foo = bar.getSomeClass(); baz.doIt(foo); // Followed by code which never again uses foo. Why??

2. Potentially frightening comments left in code such as:

// This stuff doesn't work, clean it up asap. DZ 01/01/2001

... 6 years hence...

1. Code which causes confusion over the documented API:

// This method will always return a non-null reference, or throw an exception. SomeClass foo = bar.getSomeClass(); if (foo != null) { // yet I just checked for a null return?

That's a subtle one. I could go on.

I will admit to using the prefix b on my boolean locals and method parameters but have received some grief from my peers lately and I will renew my efforts to stop this filthy habit. :)

But details aside (which will change over time based on technology) - I believe your meta-gripe is the same one I have time and again when reviewing other's code:

Take the time to do it right. Have pride in the work you do. Don't just be a coder, be a "software professional". Know your implementation language inside and out. Know your APIs. Say exactly what you mean in your code, no more, no less. Be direct and concise and make every character "count". Be consistent. Strive for elegance.

Programming is in many ways a creative endeavour. In other disciplines we have the same theme: an artist puts "too much" paint on the canvas, a novel is too wordy, or there are plot inconsistencies, the flow of a room doesn't feel right - doors are in the wrong places... but technically the specs have been met.

The same principles apply in programming, but I think they don't get enough emphasis - possibly because the profession is very technical and science oriented, asthetics are viewed with disdain. Unfortunately, having been on many large projects over the years in all parts of the lifecycle, I know it does effect the bottom line - time to market, flexibility in adding new features, consistency of the user experience, bug counts, maintainability, etc, etc. The person who commented to the effect "who cares" clearly does not get it, and may never get it.

I am not sure changing the language will get at the root of the problem, perhaps - but I think there is something less tangible that needs to be taught - either in university, or in the first couple years of a junior developer's apprenticeship.

Good stuff.

Ah, nice to know such things matter to others and that others do "get it". If only every comment were as insightful.

If these are the biggest problems you got with other people's code, I envy you. You wouldn't believe the kind of things my coworkers are up to.

Calling variables such helpful names as x and y (and not even bother to comment); typing entire programs into Workspace (and never working with classes); designing entire Smalltalk programs on paper because, well, that's how things were done in Fortran on punched cards and why change now?

Please, give me Hungarian notation any day.

[...] el blog de Ramon Leon encontré un excelente artículo listando algunas de las aberraciones que he encontrado en el código que he tenido que modificar y [...] ]]>

My biggest pet peeve is when its decided that every primary key has to have a different name, such as the table name with "Id" appended to it. I think things work much nicer when all primary keys are named 'id', (and not 'pkey'... ugh), and short aliases are used for the table names when joining them. I think folks who insist on using primary keys named something other than 'id', have not leared about aliases in SQL.

There are other reasons people do this. For example, in some db's natural joins are free, so having the address.customerId match the customer.customerId means you don't have to type the join. There's also something to be said for the customerId always being called customerId whenever possible, whether it's a primary key or a foreign key. It's not about not knowing aliases, it's about wanting consistency.

I actually favor customerId as the primary key for customer. I don't want to have to alias all the keys every time I do a multi table join, and I can type "customerId" faster than I can type "id as customerId". Why would you want all of your tables to have the same field name for the primary key?

Wow, what a great read! I had a grin on my face the whole time, nodding at pretty much everything you said, Ramon (although I'm used to formatting Smalltalk code very differently from you). Some of the comments, though a year old by now, sure exposed the level of ignorance and lack of humour of some readers, it's absolutely hilarious =o)

And for some reason, several of the fallacies you mention as well as several of the comments bring to mind Charles Babbage's response (albeit to an unrelated question), "I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a [thing]."

Seems to me that the more people rant against your rant, call you names, and take you for a "junior developer" lacking experience in large dev teams, the more likely it is they either: a) get criticised constantly for the tosh they produce and just can't take any more, or b) have been stuck for so long in the same "large dev team" where bad coding is so common that they just don't know any different.

There's nothing wrong with anyone disagreeing with your preferences, but to take it so personally that they need to act like jealous kids... sheesh, it'd be funny if it weren't so sad ;-)

And while I'm at it, here's a couple of my pet peeves in the same spirit:

1) abbreviations of any kind - unless it's a widely accepted abbreviation, spell it out, for crying out loud, or the second or two you save by typing less (not much of an argument in the days of automatic code-completion) will come back and bite you hundred-fold when you debug (if not you then anyone who will have to decipher your code later on)

2) multiple calls to non-trivial methods - use a temporary variable already, that's what they're for...

I totally agree with both of those as well. I often wonder how much the need to abbreviate directly correlates to poor typing skills. One of my favorite things about Smalltalk is that Smalltalk'ers tend not to do that, more than any other language, they cater to the code reader rather than the code writer.

You can certainly tell the bad programmers, they're the ones most offended by having their flaws pointed out. These aren't exactly earth shattering revelations, just things that tend to be found in junior level code.

My one gripe with this is the don't use XML bit. XML makes for terrible configuration files except when they must be generated and maintained by an application. Also, using XML as an "object" is usually a bad idea, but using XML as a data store is actually very effective. The XML XSLT combination can be very similar to SQL at times and can make a ton of sense.

This is my personal opinion of course and I'm honestly not the most object oriented person, so I would assume if I was a bit more attuned to OO and the awesomeness of SmallTalk then my thoughts might be different.

XML is a terrible data store, binary serialization formats are vastly smaller, faster, and can contain real objects that can be queried via the standard collections protocol. The place where XML is useful is when transporting data across the wire, especially across otherwise incompatible platforms, web services and such. It's only real value is the availability of parsers on every platform.

XSLT is a nice little functional language that makes generating HTML from XML very nice to do, it works as a nice view layer on lesser platforms, however, I'm a Seaside fan and I write my HTML directly in Smalltalk. XSLT's predicate dispatching on templates is rather nice though.

Were comments searchable in your old blog? I was trying to find your reference to Wirfs-Brock book from two years ago and after the search failing and trying to guess the post I just went to google and did a search for 'wirfs-brock site:onsmalltalk.com' But I seem to remember not needing to do that with the old blog. Do you plan to make comments searchable from inside your blog? Thanks for all the good info