Because we've all written code like this back in the day...



  • Here's a few Java WTFs I've seen recently in an app I maintain at work.
    Mind you some of them are more an example of newbie coding, but still classics:

    // context: addrByte is a byte[4] for an ip address
    long value = new Long(addrByte[i]).longValue();

    I vaguely remember the following being discouraged in my 2nd or 3rd class of Java 101, and this
    is coming from someone who I believe was one of those "I have years of experience" people.
    // part 1...
    if (initialRead == true || serverSideIoError == false)
    // part 2...
    while(entryRemoved == true)
    // part 3...
    if (monitoringInProgress == true)
    // part 4...
    if (action.equalsIgnoreCase(stop") != true &&
        action.equalsIgnoreCase("restart") != true &&
        action.equalsIgnoreCase("monitor") != true &&
        action.equalsIgnoreCase("debug=true") != true &&
        action.equalsIgnoreCase("debug=false") != true &&
        action.equalsIgnoreCase("terminate") != true)
    // ...snip a stack of similar lines...

    Oh and one of my all-time favourites:
    if (gui.rlIdHid.getValue().equals(null) || (gui.rlIdHid.getValue().equals("")))

    I'm also forever seeing default constructors (the ONLY constructor in the class, too) with a call to super();
    super() should throw a compile error IMO. "Compile error: Superfluous code, get a clue."



  • There are some cases where xxx == false (instead of !xxx) might be easier to read.

    For example,

    if (xxx == false) {
      xxx = true;
      ...
    }

    IMO this style makes it easier to spot the state transition of xxx from false to true.

    It's all subjective, though.



  • No, that == true stuff really gets me. If someone gets spooked out trying to work out the logic in:

    if (condition1 && !condition2)

    they really shouldn't be coding. The other thing that really gets me, along with superfluous calls to super (or base in C#) is people that insist on referencing everything with this. this really annoys me. It should not be used unless an ambiguity exists, any other time is ugly and annoying.

     



  • [quote user="Phill"]

    The other thing that really gets me, along with superfluous calls to super (or base in C#) is people that insist on referencing everything with this. this really annoys me. It should not be used unless an ambiguity exists, any other time is ugly and annoying.

    [/quote]

    What really annoys me is people who don't use this when accessing instance variables. Using this makes code FAR easier to read and saves you constantly scrolling around to see where variables are coming from. Local variables are obviously distinct from instance variables this way.

    To each their own!

     Also, there ARE legitimate reasons to call super in constructors you know! A call to super is not a WTF in it self.

    Bart.

     



  • [quote user="voyager"]What really annoys me is people who don't use this when accessing instance variables. Using this makes code FAR easier to read and saves you constantly scrolling around to see where variables are coming from. Local variables are obviously distinct from instance variables this way. [/quote]

    Hmmm, I generally use an _ at the beginning of instance variables for the same reason. Sometimes I use this as well though, just to be different.

     It's a crazy, mixed-up world.
     



  • If you don't know where a variable comes from, it seems you don't use any typical style in naming.

    _name - private
    name - something local / protected (you typically know which one is it then)
    Name - public

    Any problems with using this, or any other style? (m_name, _name, name, Name is also nice) Why do we need this.name or this._name?



  • [quote user="viraptor"]

    If you don't know where a variable comes from, it seems you don't use any typical style in naming.

    [/quote]

    If you work in a real shop where the code you write is added to code someone else wrote and will later be used by someone else entirely, you cannot rely on the idea that the last guy used your style of naming, nor can you rely on the idea that the next guy will understand it.

    And if the last guy and the next guy happen to agree on an alternative style, then you are the WTF.

    But "this.name" is ALWAYS an instance variable, no matter what anyone thinks about the format or spelling of "name". Nobody can change that. Its usage is clear and unambiguous in absolutely every situation, and it is therefore impossible to improve upon it.



  • [quote user="CDarklock"][quote user="viraptor"]

    If you don't know where a variable comes from, it seems you don't use any typical style in naming.

    [/quote]

    If you work in a real shop where the code you write is added to code someone else wrote and will later be used by someone else entirely, you cannot rely on the idea that the last guy used your style of naming, nor can you rely on the idea that the next guy will understand it.

    And if the last guy and the next guy happen to agree on an alternative style, then you are the WTF.

    But "this.name" is ALWAYS an instance variable, no matter what anyone thinks about the format or spelling of "name". Nobody can change that. Its usage is clear and unambiguous in absolutely every situation, and it is therefore impossible to improve upon it.

    [/quote]

     Exactly! I work on code in an environment where the team is very dynamic so people come and go all the time. Our coding stantards are simple:

     
    1) user this with instance variables

    2) use camelBack notation starting with a lowe-case letter for function names e.g. getSomeProperty()

    2) use CamelBack notation starting with an upper-case letter for class names e.g. MyClass

    We write Java code so this is a pretty standard way of doing things. The CamelBack in particular, just have a look at the Docs on java.sun.com and you'll see that's how it's done in Java. No need to invent custom styles. User the industry standard for names and make your code explicit. I like my code to read almost like English so that when I move on to other things the person who replaces me won't have to post my code up here :)
     



  • Maybe I'm dumb, what's the problem with the last one?  The fact that he didn't use a temp variable?

    And for the record, a few well placed "this" keywords can make a function much easier to read.  If you need to use naming convention to keep track of the source of a variable, you should probably be using the keyword.

    Trying to eschew all "superfluous" code will quickly make a project unmaintainable and unreadable.  For example, some programmers seem to think vowels in their variable names are superfluous.  I for one am sick of reading variable names like "nwRgMCfg".

    Really, these are all just minor syntax issues or deviations from standards.  If they are the biggest wtf's you come across count yourself lucky.  Judging by the fact that you've taken a Java 101 course, I'd recommend that you not get too cocky, and don't be too quick to look for WTF's in your coworker's code.



  • [quote user="voyager"]What really annoys me is people who don't use this when accessing instance variables. Using this makes code FAR easier to read and saves you constantly scrolling around to see where variables are coming from. Local variables are obviously distinct from instance variables this way.[/quote]

    I program in C# and I'm a recovering intellisense junkie.  this usage is automatic as a result.

    Sometimes, when I want to remember what life was like before my addiction, I actually write code that references variables I haven't declared yet. (**gasp!**)



  • The fact that he took a Java 101 class suggests that he went to college recently.  If this bothers you perhaps you should work in a nursing home.

     



  • [quote user="tster"]

    The fact that he took a Java 101 class suggests that he went to college recently.  If this bothers you perhaps you should work in a nursing home.

     

    [/quote]

     Didn't mean to imply that I have a problem with recent college grads - only that he might want to tone down the arrogance.
     



  • [quote user="CDarklock"]If you work in a real shop where the code you write is added to code someone else wrote and will later be used by someone else entirely, you cannot rely on the idea that the last guy used your style of naming, nor can you rely on the idea that the next guy will understand it.[/quote]

     

    What happened to coding standards?  My first programming internship, the coding standards were strictly enforced by a grumpy 40-something who'd been programming since the late 70s.  They included strict 80-char line wrapping (he coded exclusively in emacs), and indentation rules.

    I learned a lot from it.  And it was a hell of a lot easier to work with other people's code, 'cause it all looked the same.



  • [quote user="rmr"]Maybe I'm dumb, what's the problem with the last one?  The fact that he didn't use a temp variable?[/quote]

    The check the coder used was to prevent a NullPointerException being thrown in the case that getValue() returned null (which btw it never can in this system).

    The problem is that rather than using getValue()==null, they used getValue().equals(null), which will throw an exception in itself (if getValue() were null).

    [quote user="rmr"]Judging by the fact that you've taken a Java 101 course, I'd recommend that you not get too cocky, and don't be too quick to look for WTF's in your coworker's code.[/quote]

    Umm... I took this course only because I HAD to (ie. it was a core subject).  I'd been using Java for at least 2 years prior, and coding for at least 10 years before that.  I'd recommend that you don't turn a simple comment into a personal attack.

    [quote user="rmr"]Trying to eschew all "superfluous" code will quickly make a project unmaintainable and unreadable.  For example, some programmers seem to think vowels in their variable names are superfluous.  I for one am sick of reading variable names like "nwRgMCfg".[/quote]

    I agree on this point, unfortunately I have to use our stupid naming convention or I get told off in code reviews. :(

    [quote user="voyager"]Also, there ARE legitimate reasons to call super in constructors you know! A call to super is not a WTF in itself.[/quote]

    Explain please?  I'm talking about a call to super(). ie. the default constructor.  If you need to call something other than that, then of course you should make a call to super(whatever).  Explicitly calling the default constructor serves no purpose and just takes up extra space on my screen and extra disk space in our version control system (at my work, upgrading our server's <100gb hard drive is too expensive, apparently).

    [quote user="merreborn"]What happened to coding standards?  My first programming internship, the coding standards were strictly enforced by a grumpy 40-something who'd been programming since the late 70s.  They included strict 80-char line wrapping (he coded exclusively in emacs), and indentation rules.[/quote]

    Fortunately I do a majority of the Java code reviews here, so I get to tell people off if they don't conform to standards (ie. my own) :)  That and I personally configured the Eclipse code formatter on everyone's machine to be exactly the same, and people get a slap on the wrist from me if they check code in without first formatting it.  Oh and 80 characters is so last century :) 23" widescreen ftw!

    As for using the "this" keyword, I'll agree with the concensus here that it makes code clearer, but personally I've never really thought about it since Eclipse syntax highlights fields automatically.  If it weren't for the fact that no-one at my work uses "this" unless they have to, I'd start using it more.

    Oh and a comment to everyone here -- there's no such thing as an "instance variable" in Java, it's called a field. :)

     



  • re: using 'this'

    I work on a system that is developed by multiple teams in multiple geographically diverse locations. The folks in NY use PC's and have IDEA (intellisense, etc.). The folks in London use Solaris and pretty much work with vi (IDEA hasn't been deployed there yet). As such, the London folks don't have the luxury of code-highlighting, so even though we (in NY) can readily see the different highlighting for class fields, using 'this.xxx' really makes their lives easier.

    Different strokes....

    My $0.02


Log in to reply