Home

News: Humor: Why your code sucks

  1. Humor: Why your code sucks (76 messages)

    Sure, it's easy to see how badly other developers' code sucks but what about those carefully crafted lines of genius that you produce? Here are some simple examples of why even your code sucks, courtesy of Dave Astels.

    Your code sucks if it doesn't work.
    Does your code work? How do you know? Can you prove it?

    If you don't have tests for your code, it sucks. And I mean comprehensive, fine grained, programmer tests (aka something like unit tests), as well as higher level functional and integration tests. Tests that are automated. Tests that are run routinely. With the programmer tests run after any change to the code.

    Without adequate tests (in terms of both quantity and quality) you simply can't have confidence that your codes works as required. And even if you are confident with your work... why should anyone else be? What about people who work on the code later? How do they know it still works after they make their changes?

    Your code sucks if it isn't testable.
    OK, so you decide to add tests to your code. That typically isn't so easy. The odds are that your code wasn't designed and/or implemented to be easily testable. That means you will have to make changes to it to make it testable... without breaking any of it (this is usually called refactoring these days). But how can you quickly and easily tell if you've broken anything without that comprehensive set of fine grained tests? Tricky.

    It's even trickier than that. If you take the approach that you'll write tests for all your code after you write the code, you have to go to extra effort to try and design/write the code to be testable.

    Maintaining an adequate level of testing when writing tests after the code being tested takes time and planning. And if you have to do additional work to make your code testable... well... that sucks.

    Writing tests before you write the code means that the code is testable by definition. If you work one test at a time, you reap even more benefit, as each test only requires incremental changes to code that you know is solid.

    Your code sucks if it's hard to read.
    Code should be easy to read. Steve McConnell made the statement at his SD West '04 keynote that code should be convienent to read, not convienent to write.

    There are several things involved here. Choosing good names that are self-explainatory is a good place to start. Strive for simple solutions, even if they are more verbose or inefficient. Whether inefficiency is a problem won't be known until profiling is done later in the project, in a real production situation.

    Choose style and formating conventions early in the project, and conform to them. Require that everyone conform to them. This will be easier to do if everyone has a hand in deciding on the conventions and buys into them. This will make the code uniform and thus easier to read.

    And get rid of any and all duplication. More on this later.

    Your code sucks if it's not understandable.
    This is closely related to the previous point. Code can be readable, but still not easily understood. Maybe it reads well but is misleading. Maybe you took the time to pick a good name for that variable, but the way it's used and what it means has changed, but the name hasn't. That's worse than using a cryptic name... at least in the latter case, the reader knows the name is meaningless. If the name is missleading, the reader can make ungrounded assumptions about what's happening in the code, leading to misunderstanding, and eventually bugs.

    Your code sucks if it dogmatically conforms to a trendy framework at the cost of following good design/implimentation practices.
    For example, Bob Martin recently raised the issue of dogmatically using private fields and getters/setters for a simple data structure (e.g. a DTO). If a field is transparently readable and writable why not simply make the field public? In most languages you can do that. Granted, in some you can't. For example, traditionally in Smalltalk all fields are private and all methods are public.

    In general it's a good thing whenever you can throw out, or avoid writing, some code. Using a heavy framework generally requires that you must write a significant amount of code that has no business value.

    There are a variety of lightweight frameworks for Java that are a response to the heavyweight frameworks (e.g. EJB) that have become matters of dogma lately. O'Reilly has a new book out on this topic, coauthored by Bruce Tate.

    When making framework decisions, consider if a lighter framework will do the required job. Using something like Hibernate, Prevayler, Spring, PicoContainer, NakedObjects, etc. can be a real win in many situations. Never blindly adopt a heavy framework just because it's the current bandwagon. Likewise, don't blindly adopt a lightweight framework in defiance. Always give due consideration to your choices.

    Your code sucks if it has duplication.
    Duplication is probably the single, most important thing to banish from your code.

    Duplication can take several forms:

    • textual
      This is the simplest and often the easiest to find. This is when you have sections of code that are identical or nearly so. This is often a result of copy & paste programming. Several techniques can be used to eliminate it, including: extracting methods and reusing them, making a method into a template method, pulling it up into a superclass, and providing the variations in subclasses, and other basic refactorings. See Fowler's "Refactoring" for more detail.
    • functional
      This is a special case of textual duplication and is present when you have multiple functions/methods that serve the same purspose. This is often seen in projects that are split up between groups that don't communicate enough. This could be a result of copy & paste, or it could be the result of ignorance of existing code or libraries. Practices and policies that encourage and promote knowledge of the entire codebase and all libraries and frameworks being used can help avoid functional duplication.
    • temporal
      This is a bit odder, more obscure, and not as easy to find. You have temporal duplication when the same work is done repeatedly when it doesn't have to be. This isn't a problem in the same way as the previous two forms of duplication since it doesn't involve having extra code laying about. It can become a problem as the system scales and the repeated work starts taking too much time. Various caching techques can be used to address this problem.
      Of the three types I've identified above, textual duplication is the worst. It is the quickest to bite you as the system grows. It has a nasty habit of being viral: when you see code duplicated in the system, it can be tempted to think "Oh, well then, it's not a problem if I just nic this code and put a copy of it over here and fiddle it a bit. Hey, everyone else is doing it!" It's a lot like the Broken Window that Dave Thomas & Andy Hunt talk about. If you don't keep on top of the little things as they appear, the whole thing will soon go down the toilet.
    Summary

    So, chances are pretty good that some of your code sucks.

    What are you going to do about it? Well, first you have to recognise the fact (and hopefully this article has helped with that) and admit that there's a problem.

    Then you have a choice. You can choose to do something about it. You can learn new ways to work... ways that help you write better code. That's great. If only one programmer out there does this, I'll be happy.

    Your other option is to do nothing about it, and continue writing code the way you always have.

    It's your choice. Choose wisely.

    Read this and other comments at Dave Astels' blog.

    Threaded Messages (76)

  2. Humor: Why your code sucks[ Go to top ]

    Hi, my name is Rickard. My code sucks.
  3. Humor: Why your code sucks[ Go to top ]

    Hi, my name is Rickard. My code sucks.
    Rickard, i dont think so :).
  4. That was a parody on a greeting message of Anonymous Alcoholics :)

    P.S. My code sucks.
  5. Humor: Why your code sucks[ Go to top ]

    Rikard Oberg's code sucks?? come on, i don't buy it :-)
  6. Humor: Why your code sucks[ Go to top ]

    Who is Rickard Oberg?
  7. Who is Rickard Oberg?[ Go to top ]

    I guess he is that RMI programmer who knows a bit of XDoclet.

    See for yourself.
    http://www.amazon.com/exec/obidos/search-handle-url/index=books&field-author=Oberg%2C%252520Rickard/103-0400250-2825440

    He also like to spend a bit of his time talking
    http://www.theserverside.com/news/thread.tss?thread_id=9967

    and like to think randomly
    http://jroller.com/page/rickard
  8. Who is Rickard Oberg?[ Go to top ]

    Thanks.

    I thought he was a beatle :-)
  9. Who is Rickard Oberg?[ Go to top ]

    I thought he was a football player who had highest no of touchdown last season. :)
  10. Codes[ Go to top ]

    I thought he was a football player who had highest no of touchdown last season. :)
    Naah he's the guy who has sucking codes....thats good you dont need a vacuum cleaner anymore ;-)
  11. Who is Rickard Oberg?[ Go to top ]

    I guess he is that RMI programmer who knows a bit of XDoclet.See for yourself.http://www.amazon.com/exec/obidos/search-handle-url/index=books&field-author=Oberg%2C%252520Rickard/103-0400250-2825440He also like to spend a bit of his time talkinghttp://www.theserverside.com/news/thread.tss?thread_id=9967and like to think randomlyhttp://jroller.com/page/rickard
    Um...what's JBoss?
  12. Humor: Why your code sucks[ Go to top ]

    Who is Rickard Oberg?
    Dunno, but his code seems to suck bigtime ...
  13. Who is Rickard Oberg[ Go to top ]

    Who is Rickard Oberg?
    You must be kidding me. You don't known who Rickard is?

     :-)

    Rickard Oberg is the creator of XDoclet and Webwork. Architect of the core of JBoss app server (Jboss micro-kernel where everything else is plugable as MBean). Active in the AOP space and currently working on CMS.

    regards
  14. Humor: Why your code sucks[ Go to top ]

    Who is Rickard Oberg?
    I'm Spart^H^H^H^H^HRickard Oberg!
  15. Humor: Why your code sucks[ Go to top ]

    Hi, my name is Rickard. My code sucks.
    What have you decided to do about it ? Can we know ? We will respect your choice, but plz choose wisely. ;-)
  16. Humor: Why your code sucks[ Go to top ]

    Hi, my name is DNA. My "code" sucks also.

    How in the world did the author arrive at these standards for suckiness? For example, how could anybody conclude that duplication is always sucky? In any large piece of software, the number of dependencies will tend to vary inversely with the degree of duplication. In other words, coders tend to eliminate duplication by factoring code into class hierarchies and helpers, with the result being that a decrease in duplication tends to cause a corresponding increase in the number of dependencies that any particular piece of code has. As almost any developer of a large piece of software will know, managing the dependencies of a large class hierarchy and set of helpers is time-consuming, costly and completely sucks.

    I suggest that successful natural codes (e.g. DNA) be considered when deciding upon standards for suckiness. DNA is very messy, but it works well and versions well.
  17. Humor: Why your code sucks[ Go to top ]

    Hi, my name is DNA. My "code" sucks also.How in the world did the author arrive at these standards for suckiness?
    Maybe he sells a book on test driven design and wants you to buy one? In other words, if you don't want to suck anymore, pay the man.
    For example, how could anybody conclude that duplication is always sucky? In any large piece of software, the number of dependencies will tend to vary inversely with the degree of duplication. In other words, coders tend to eliminate duplication by factoring code into class hierarchies and helpers, with the result being that a decrease in duplication tends to cause a corresponding increase in the number of dependencies that any particular piece of code has. As almost any developer of a large piece of software will know, managing the dependencies of a large class hierarchy and set of helpers is time-consuming, costly and completely sucks.
    It's definitely better than fixing one bug a dozen times in a dozen sections of cut-and-pasted code.
    I suggest that successful natural codes (e.g. DNA) be considered when deciding upon standards for suckiness. DNA is very messy, but it works well and versions well.
    Nah, DNA is just the machine code. The actual design (AKA source code) is kept somewhere else.
  18. Humor: Why your code sucks[ Go to top ]

    I couldn't disagree more. Duplication ALWAYS sucks! Just because something is more difficult (e.g., managing complex dependencies), this does not mean it's not the "right" thing to do. More often than not, the opposite is true.
  19. Humor: Why your code sucks[ Go to top ]

    Duplication ALWAYS sucks!
    Huh?

    Are you annoyed that you have TWO hands? TEN fingers? Perhaps you'd prefer to write your code with just one hand and one finger.

    I believe that if you do even a casual survey of some of the successful systems (both natural and man-made) that are part of your everyday life, you will find lots of, and sometimes massive amounts of redundancy. And I believe that you will find that the redundancy tends to be a *feature* that increases the robustness of those systems, not a bug that worsens those systems.

    I agree that duplication has a cost associated with it. But so do dependencies. And in many scenarios (e.g. large software projects, especially ones where the developers are distributed), the cost of managing dependencies can far exceed the cost of duplication.

    All costs must be considered when deciding upon a coding strategy for a project. It is simply not good engineering practice to conclude in advance that for every project duplication "ALWAYS" sucks. Sometimes duplication is the greatest cost, and so should be minimized. But very often, the opposite is true, and duplication should be accepted and maybe even encouraged.

    In some scenarios, duplication is an optimization that may be done to reduce the costs associated with dependencies, especially the time cost. For example, consider how long it would take to implement something like Linux (or the JDK) if before writing a line of code, a developer had to first ensure that no other developer had already written the same line of code. And consider how long such a check-before-writing developer would be tolerated on a project. Not very long, I think. After a while, the cost of answering that developer's questions would far exceed the worth of their code contributions.

    In other words, sometimes the best approach is Mother Nature's approach: just do it. (Sorry Nike, Mother Nature thought of that idea long before you did.)
  20. Humor: Why your code sucks[ Go to top ]

    Are you annoyed that you have TWO hands? TEN fingers? Perhaps you'd prefer to write your code with just one hand and one finger.
    Hmm. not exactly duplication. A left and right hand. Some with fingers, feet and toes.
  21. Humor: Why your code sucks[ Go to top ]

    Are you annoyed that you have TWO hands? TEN fingers? Perhaps you'd prefer to write your code with just one hand and one finger.
    Hmm. not exactly duplication. A left and right hand. Some with fingers, feet and toes.
    Same with. Otherwise it is just weird.
  22. Humor: Why your code sucks[ Go to top ]

    What about stop writing code just use the a tool like MS Visual Studio that generates our code. We can put the blame on the guys who built
    the tool


    regards
    Debu
  23. Humor: Why your code sucks[ Go to top ]

    What about stop writing code just use the a tool like MS Visual Studio that generates our code. We can put the blame on the guys who builtthe toolregardsDebu
    Yes this is the best way.
    My code is sexy, your code sucks becouse it is your code.
  24. Humor: Why your code sucks[ Go to top ]

    Now this really is funny...

    So if I have a twin brother, he's redundant?
  25. Humor: Why your code sucks[ Go to top ]

    Yes. Just ask a biologist ;-)

    I agree that this is all funny.

    I take sides with those who have declared that according to the original poster's criteria, their code sucks. My code sucks. However, given that Rickard had already done such a simple and elegant job of debunking the original poster's comments (hopefully the poster "got it"), it seemed wrong of me to say "My code sucks" in the same way that Rickard had. Thus my DNA "code" comment.
  26. Humor: Why your code sucks[ Go to top ]

    What's the point in arguing, it still sucks!

    BTW I am Artem Yegorov and my code goes beyond suckiness, I mean if you really unfocus your eyes looking at iy, you'll one big nice 3D shape depicting "666".
    It rotates too...:-)

    Here is to everlasting suckiness of any code, as only the code that sucks saves your job...Like a large enterprise system user cares how many tests and cool patterns you've used or if you know what GoF is, if you are 6 months behind schedule and asking for another million $ to write a thousand more tests. Hey, they just want it to work. For the sake of your employer and paycheck let your code be sucky.

    And another thing, if you really, trully wish for your code not to suck, do not write any. Let everybody else's code suck, so you can preach on suckiness of their code.
  27. Duplication not always sucks[ Go to top ]

    As long as you know where the duplication is....
  28. Humor: Why your code sucks[ Go to top ]

    Hi, my name is Rickard. My code sucks.
    good to know that you are aware. your code started sucking when you first touched this JBoss thing. thank God, B. Burke saved the project and made it something useful. then you wrote that RMI book, encouraged people to use it and caused lots of headache with stubs, codebases. you didn't stop there and wrote this ugly xdoclet that everyone wanted to be part of this sin. didn't your mom told you not to come up with a new funky template language while we have the beloved velocity. forget all these but what is that webwork thingy. you even realized that you code sucked and stoped maintaining it. now Jason and his friends clean up your dirty code. good luck Jason. later this AOP madness. as if it wasn't enough to write sucking code, you messed up the way people write code. can't you live like a normal developer. we have inheritance/polymorphism/encapsulation, why do we need mixin, introduction, aspect, advice, objectid, abstract models and such. we were lucky that you didn't make your AOP framework public. please keep it to yourself, your code sucks man!!

    -talip
    ps- Rickard, we are lucky to have you with us in this community.
  29. Humor: Why your code sucks[ Go to top ]

    your code started sucking when you first touched this JBoss thing.
    Actually, my code sucked way waaay before that, but ok, whatever.
    then you wrote that RMI book, encouraged people to use it and caused lots of headache with stubs, codebases.
    Yeah, that was downright evil of me. What can I say... I was (/is?) a naive twat who didn't(/don't) know better.
    you didn't stop there and wrote this ugly xdoclet that everyone wanted to be part of this sin.
    And the funny thing is that if it wasn't for that earlier sin - the EJB stuff - I wouldn't have written it. "One logical step at a time", or so the saying goes. A downward spiral to the ultimate suckiness.
    didn't your mom told you not to come up with a new funky template language while we have the beloved velocity.
    Yeah, that template stuff was evil, although in my defense it got even more evil once I left the project.
    forget all these but what is that webwork thingy. you even realized that you code sucked and stoped maintaining it.
    Hm... is it possible to "stop maintaining" if I didn't "start maintaining" it in the first place? Hm..... almost like "stop astroturfing" even if you don't "astroturf" in the first place. Tricky tricky.
    later this AOP madness. as if it wasn't enough to write sucking code, you messed up the way people write code. can't you live like a normal developer. we have inheritance/polymorphism/encapsulation, why do we need mixin, introduction, aspect, advice, objectid, abstract models and such.
    Because it lets you write sucky code at a totally unprecedented rate?
    we were lucky that you didn't make your AOP framework public.
    I know. That's what I said. My code sucks. Sheesh, don't you people listen...

    So here's what I don't get. Considering the complete and total suckiness of the code I have written, why oh why are people using it? They tell me that there are even books about both JBoss, XDoclet, and WebWork. That sucky code!? I mean, I wrote my first JUnit test case yesterday. Literally. If tests are the main measurement of suckiness my code sucks to the umpteenth power of unbelievable suckdom.

    On the other hand, as another sucker pointed out:
    Axiom:

        2. There is a better way to do it.

    Conjecture:

        There is always a better way to do it.

    Theorem:

        All code sucks.
    Hence, my first comment was actually a non-statement. If all code sucks, then of course my code sucks. The difference, really, is simply whether you are aware of it or not.

    Something to think about.
  30. Humor: Why your code sucks[ Go to top ]

    Hm... is it possible to "stop maintaining" if I didn't "start maintaining" it in the first place? Hm..... almost like "stop astroturfing" even if you don't "astroturf" in the first place. Tricky tricky.
    This is atleast a tad more funny than the article.
     In our country we don't suck at the same thing for a long time. See. We program for 4 years and then our code sucks. We become a "TECH. LEAD" after just 4 years( no coding ) and our team sucks. After 2 more years we are "TECH. ARCH'S" ( no design, only 'architecture' ) and our architecture sucks. After that you are a PM and the management sucks.
     The trick is to suck for some time at something and move on to something else.
  31. avoid java[ Go to top ]

    Hi, my name is Rickard. My code sucks.
    then use .NET. J2EE makes ur code suck.
  32. use .NET[ Go to top ]

    .NET? MS .NET? Doesn't MS stands for MacroSucks ... :-)
    Bye
    Stefano
  33. Just read tis[ Go to top ]

    I just read tis.... from the bilelog link.... I guess my code sucks too.... but it works!
  34. Humor: Why your code sucks[ Go to top ]

    My code sucks.

    My code sucks more.
  35. Humor: Why your code sucks[ Go to top ]

    I'm not sure I see the humour in this. Unless it's in the old-fashioned sense of being bilious.

    There are a couple of amusing bits, I suppose:

    The image of a broken window disappearing down the toilet.

    And the concept of people jumping on the EJB bandwagon. Mmmm....
  36. Re: Humor: Why your code sucks[ Go to top ]

    It's funnier than "Tales from the Server Side". ;¬)
  37. Re: Humor: Why your code sucks[ Go to top ]

    When a title starts with "Humor:", I expect to laugh. But then the article goes on to dryly preach about unit testing, code reuse, code readability, etc. Not that it isn't a good message, but it's the same message you get from any programming website, magazine, or book, and I just didn't see any humor in it. "Your code sucks because <preach on for 3 paragraphs>" just doesn't tickle my funny bone.
  38. Re: Humor: Why your code sucks[ Go to top ]

    When a title starts with "Humor:", I expect to laugh. But ...
    The humor isn't from the article in itself, but from the very first post.
    Hi, my name is Rickard. My code sucks.
    It scheme!
    FYA
    P.S.: this post is a dry joke, too.
  39. Not funny[ Go to top ]

    I'm not sure I see the humour in this.
    I didn't write it as humour.. rather in all seriousness.

    The typical codebase sucks. In various ways.

    Dave
  40. Humor: Why your code sucks[ Go to top ]

    Well, my code does suffer from any of the above problems.

    I can now loudly proclaim... "MY CODE BLOWS!!"
  41. CORRECTION[ Go to top ]

    Well, my code does not suffer from any of the above problems.I can now loudly proclaim... "MY CODE BLOWS!!"
    My code may blow, but my typing sucks!
  42. CORRECTION[ Go to top ]

    >My code may blow, but my typing sucks!
    My typing *doesn't* suck, but my keyboard does.

    And my code sucks so bad I went into marketing. Though come to think of it, that may be the artificial limit on lines-per-procedure built into the compiler I was using that forced me to strip comments. Use of the word 'procedure' should trigger thoughts of how long ago this was.
  43. Exception messages suck ...[ Go to top ]

    I have seen an exception message like this ..
    [OBJECT NAME REMOVED] is null. What the hell is going on ??
    and another one ...
    How the @#%^&#$ the system is going to process the request.
    and i supposed the programmers were supposed to be polite :)
  44. A missing factor[ Go to top ]

    I think Dion missed one point:
    the code sucks if it lacks logging. Very often before coming to the code, coming to the log helps a lot (if the log is well structured of course).
    Just my 2 cents,
       Giovanni
  45. A missing factor[ Go to top ]

    I think Dion missed one point:the code sucks if it lacks logging. Very often before coming to the code, coming to the log helps a lot (if the log is well structured of course).Just my 2 cents, Giovanni
    Of course, adding logging might violate this - "Your code sucks if it's hard to read." Oh, what to do. [hand wringing]
  46. ImaCodeSucker[ Go to top ]

    Of course, adding logging might violate this - "Your code sucks if it's hard to read." Oh, what to do. [hand wringing]
    Heh, use AOP for logging (if possible... innnit?).

    BTW. My code sucks a lot... a test? what'sdat? ;)
  47. hmm[ Go to top ]

    My code is sexy. Like me.
  48. Yes, my code sucks...:)[ Go to top ]

    Yes, my code sucks...:)
  49. How to write unmantainable code[ Go to top ]

    your code sucks, but it is not enough?
    Here is how to write unmantainable code : http://mindprod.com/unmain.html
    The best coding tips ever.
  50. Roedy did it properly![ Go to top ]

    http://mindprod.com/unmain.html

    Yes, Gabriel, this is the best.
  51. OT: J2SE 5.0 has been released[ Go to top ]

    Hello TheServerSide-Guys,

    J2SE 5.0 has been released (for several hours) and still no news ;-)

    Cheers
    Michael
  52. 90 days...[ Go to top ]

    Hi my name is paskos and it's been 90 days since I didn't write code that sucks.
  53. No, Your code sucks![ Go to top ]

    Your code sucks because:
    1. The logic is spread out all over the place. I can't find out where the work is getting done without tracing through loads of files.
    2. There is a better way to do it.
    3. It is "commentated" -- the comments say less than the code does and take up twice the space. See also "textual duplication".
    4. It is overly procedural, rather than rule-based, data-driven, or whatever else you could have done.
    5. You wrote your own framework/library.
    6. You used someone else's framework/library to the detriment of your design.
    7. The program runs slowly and you refuse to admit that this was caused by bad code. If you test first, why not test performance first too? It's a functional requirement!

    P.S. My code sucks.
  54. Your code sucks if[ Go to top ]

    You've actually written it. If it's still just a gleam in your eye, then your code is awesome.

    Here's to code that sucks!
  55. Your code sucks if[ Go to top ]

    Word.
  56. No, Your code sucks![ Go to top ]

    Axiom:
    2. There is a better way to do it.
    Conjecture:
    There is always a better way to do it.
    Theorem:
    All code sucks.
    Proof is left as an exercise for the reader.
  57. Edmund Spenser would say[ Go to top ]

    It is through sucking, that humanity crawls towards salvation. Well he wouldn't say it quite like that. He would use middle english, lots of rhymes and terms like Mutability. The code has to suck for programmers to learn and strive towards lesser degree of "suckiness".
  58. There is a hidden gem[ Go to top ]

    There is a hidden gem in the article: The definition of the 3 types of duplication. May this open the eyes of those developers that think that "copy&past" is the only way to duplicate code.
  59. if (sucks)
        return sucks;
    else
        return !sucks;
  60. Curly braces[ Go to top ]

    you forgot the curly braces therefore your code sucks! :)
  61. That code sucks![ Go to top ]

    if (sucks)     return sucks;else    return !sucks;
    And just how do plan on testing that? No comments? This code sucks!
  62. That code sucks![ Go to top ]

    if (sucks)     return sucks;else    return !sucks;
    And just how do plan on testing that? No comments? This code sucks!
    // always returns true
  63. Humor: Why your code sucks[ Go to top ]

    Your code sucks if it is not generated, but generated code sucks more. Reflection is a compromise, but it sucks too.
  64. Generated Code[ Go to top ]

    I am hardly convinced that I cannot write a program which generates *some* code better than *most* developers will *bother* to write. A human brain is wasteful if used as a rote code-generator.
  65. Yes, I am a codesuckaholic. But I did write my very first JUnit test yesterday. Eclipse made it super easy, and now I am addicted... uhh, can you write <em>too<em/> many tests?

    Milhouse
  66. Sucky tests for non-sucking code[ Go to top ]

    Your code sucks if it isn't testable.
    Sine most of the tests are API-base, script-based or application wrapped around managing the latter, we have an interesting thing:

    a) test, being essentially a piece of code, needs to adhere to the same non-suckiness rules as any other code and one of the criteria is having tests which in their turn need tests and so on and so forth which in turn violates duplication as we will be writing tests over tests and would probably in the end resort to cut and paste, after say 400th iteration of this vicious cycle...

    b) test, being essentially a piece of code, but such that does not follow/pass any of the above described rules, is a piece of sucky code and therefore is a sucky test, so if the code tested by a sucky test is successful, the code is sucky itself and therefore any code sucks no matter what
    Your code sucks if it's hard to read.
    For people that cannot read code, any code sucks. If we say that a majority of people cannot read code and majority is right, any code sucks as it is unreadable.
    Your code sucks if it's not understandable.
    Since we all read differently and adhere to different psychological patterns even being developers we cannot read code that is not compatible with our visual comprehension of format and style, since there is no way of knowing anybody else's perception of code "look and feel" we may say that there will always be people who will not be able to read your code and therefore it sucks.

    And at last, for those who is still reading this "sucky" text:

    1)Any code sucks, because there will always be people who say so
    2)Any code sucks, because there will always be people who listen to what other people say
    3)Any code sucks, because your code is always better and anybody else's code sucks and that is the most important point - whichever way we come up to proclaim other people code sucking, is irrelevant, be so lack of tests, redundancy and unreadability. In the end it is your code vs other's. Which one sucks?

    I am for people coming out of this stagnation and freely admitting that it is their code that sucks, and other's...Well, who cares?

    If all above would be code, it would suck, but since it is not, well, no comment...
  67. Humor: Why your code sucks[ Go to top ]

    As long as I'm paid (well) for my code that sucks, I'm happy.
  68. being paid for code that sucks[ Go to top ]

    As long as I'm paid (well) for my code that sucks, I'm happy.
    Well, then IMHO you shouldn't be programming.
  69. WTF ???[ Go to top ]


    The code-sucks portal:
    http://www.thedailywtf.com/
  70. WTF ???[ Go to top ]

    The code-sucks portal:http://www.thedailywtf.com/
    Now. That code really does suck. Its not sexy either. Nor is the author sexy. Unlike me and my sexiness.
  71. On the other side of the coin[ Go to top ]

    I tend to think programming genius happens by luck. considering how many factors must line up perfectly, true programming genius take more luck and hardwork than smarts and talent. But since all code sucks, one might define genius as "sucks the least".
  72. If a field is transparently readable and writable why not simply make the field public?

    i thought this was to make client code not dependent on the implementation of the class - eg in future the field that is accessed directly could be stored in a different way?

    the only time i don't do this is in private-use code normally - i don't see any reason /not/ to do it dogmatically
  73. Humor: Why your code sucks[ Go to top ]

    I am Rodney Dangerfield of programming.
    My code sucks; it got no respect, when manager saw it he resigned. My code is so unsexy that they use it in prisons to cure sex offenders.

    http://www.amazon.com/exec/obidos/ASIN/0066211077/qid=1096673446/sr=ka-1/ref=pd_ka_1/104-7246151-7727122
  74. Humor: Why your code sucks[ Go to top ]

    My code clearly sucks more than your code. Testing is for fools, consultants and thoughtwankers. Long live Perl!
  75. Humor: Why your code sucks[ Go to top ]

    All programmers think they are smart but they actually sucks!!!
  76. Loops[ Go to top ]

    Hello, my name is Mike and my code sucks.
    I would also like to point out that i never got past the test portion of the news. allow me to point out the reasons why....

    first, if you write tests for your code, then you are obviously going to want tests for the tests to make sure the tests test your code, and if you write tests for the tests then you will wants tests for the tests tests to make sure the tests tests works so that the tests tests tests the tests and so on and so forth..which creates a never ending loop which will do one of two things..
    1. you will never get past writing tests for your code meaning all you will ever write are tests and no actually functioning code or..
    2. you will end up in a mental institution trying to get out of writing tests for your tests for your tests and so on and so forth..

    which made me think more..

    this may be why we have microsoft, they seem to skip the testing phase completely and go straight to the production phase, thus creating a monopoly. of course none of it will ever work properly cause they never wrote tests but since everybody else is busy writing tests or checking themselves into a mental institution it does'nt matter since they're the only people creating programs.

    just a few thoughts :)
  77. Private fields[ Go to top ]

    Bob Martin recently raised the issue of dogmatically using private fields and getters/setters for a simple data structure (e.g. a DTO). If a field is transparently readable and writable why not simply make the field public? In most languages you can do that. Granted, in some you can't. For example, traditionally in Smalltalk all fields are private and all methods are public.
    Ahem. Even if the class is just an struct (or DTO as people likes to call it now), then you must remember that sometimes structs need to be treated as unions, something that in Object Orientation is usually implemented through inheritance, since unions are too error prone.

    So when "a.x = Person;" needs to be redefined in a subclass (of this DTO) to send an email, well that assignment doesn't cut it, while "a.setX( Person );" can cut it by virtue of overriding (a.k.a polymorhism). I know C# does the trick by using properties, probably Java could do the same trick here.