 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / August 2007rant: why is it acceptable to be this... lazy?
So I've been working at a company that shall remain unnamed for the time being for almost 3 months now. In that time, I've taken over for a developer that was leaving, as well as started some brand new projects from scratch. The brand new stuff has been fairly uneventful and successful. I'm not trying to toot my own horn, I admit that the new projects have been quite limited in scope and requirements. I was warned that the legacy stuff can be rather tough to get a handle on right away. Boy, was that an understatement. I can understand when something is written with sparse documentation or somewhat inconsistent API or patterns due to lack of time, changing requirements, or who knows what else. When I got here, there was no version control in use whatsoever. Deployments were made by carefully moving specific binaries (class files) from environment to another because, as it turned out later, certain class files contained hardcoded environment-specific configuration (can they even be called that?) parameters. I was willing to go along with just about anything and quietly implement all the necessary clean-ups. But every now and then I find something that just stops me in my tracks and I can't help but wonder what sort of hard drugs the person had to be on in order to write something like this. Here's today's sample: boolean debug = Boolean.valueOf("true").booleanValue(); WTF WTF WTF WTF WTF!!!!!!! ... >boolean debug = Boolean.valueOf("true").booleanValue(); a) is the hourly rate of pay worth it? b) if so.. get over it. Sh*t code is bread and butter for a contrator. c) if not.. get a different job, and stop stressing. I hear McDonald's is hiring. (they don't offer you the big bucks just because you can sling burgers, so expect a little less stress) >WTF WTF WTF WTF WTF!!!!!!! Yeah.. See the 'McDonalds' option. Or grow up and get over it ( and add a 'premium rate' to the idiot customers that make you feel that way ;).  SignatureAndrew Thompson http://www.athompson.info/andrew/ > .. > [quoted text clipped - 17 lines] > > Message posted viahttp://www.javakb.com He said it was a rant, so let him rant. As for me, I agree with the original post. Software development is an art, and too many people don't even know how to hold the brush. Hi! > He said it was a rant, so let him rant. As for me, I agree with the > original post. Software development is an art, and too many people > don't even know how to hold the brush. Amen, brother... I guess most of us have had our share of code like this. But somehow you never stop wondering how someone illiterate enough to write such stuff was able to get the job in the first place... Regards, Phil > > He said it was a rant, so let him rant. As for me, I agree with the > > original post. Software development is an art, and too many people > > don't even know how to hold the brush. True enough, although the real problem is that, as with real art, the people paying for it often wouldn't know it if it slapped them in the face. > I guess most of us have had our share of code like this. But somehow you never > stop wondering how someone illiterate enough to write such stuff was able to > get the job in the first place... See above. SignatureC. Benson Manica | I appreciate all corrections, polite or otherwise. cbmanica(at)gmail.com | ----------------------| I do not currently read any posts posted through sdf.lonestar.org | Google groups, due to rampant unchecked spam. > He said it was a rant, so let him rant. As for me, I agree with the > original post. Software development is an art, and too many people > don't even know how to hold the brush. Sort of. The difference is that in art, the appearance to the viewer is all that matters, and it's better to produce nothing than to produce something that people don't want to see. In software development, there are all sorts of good reasons why something ugly happens, and it's often better to have something ugly than something that cost too much, or exceeded its schedule, or otherwise resulted in problems for the employer. If your contract/boss says you deliver by Friday afternoon, then you do your best to deliver by Friday afternoon, no matter how terrible your week was, or how bad the code is. SignatureChris Smith >> He said it was a rant, so let him rant. As for me, I agree with the >> original post. Software development is an art, and too many people [quoted text clipped - 11 lines] > do your best to deliver by Friday afternoon, no matter how terrible > your week was, or how bad the code is. It's code that's been made ugly in ways that can't possibly have any mitigating advantages that seems so perverse. Then there's the fact that so many "economies" are false ones, the most obvious being "There isn't time to write unit tests". Perhaps a better analogy is that software development is a learned skill like hitting a baseball, and too many people hold the bat with their feet. > >boolean debug = Boolean.valueOf("true").booleanValue(); A fine argument for getting oneself a quality IDE that can make un-suckifying such code a breeze, as well as reduce the likelihood of seeing it at all. > b) if so.. get over it. Sh*t code is bread and butter for a contrator. Mostly true, although if one is looking for resume bullet points there are better ways to spend one's time. > c) if not.. get a different job, and stop stressing. I hear > McDonald's is hiring. (they don't offer you the big bucks > just because you can sling burgers, so expect a little less > stress) Having worked fast food, I can honestly say that flipping burgers while simultaneously trying to put burgers on buns with the right toppings and clean up day shift's crap is plenty stressful. SignatureC. Benson Manica | I appreciate all corrections, polite or otherwise. cbmanica(at)gmail.com | ----------------------| I do not currently read any posts posted through sdf.lonestar.org | Google groups, due to rampant unchecked spam. ... > boolean debug = Boolean.valueOf("true").booleanValue(); ... That sort of thing can arise due to a series of changes, combined with a possible intent to change back. Suppose the original intent was to have a String, obtained e.g. from a file, that says whether to enable debug: boolean debug = Boolean.valueOf(enableDebug).booleanValue(); With 1.5 or later, it should be: boolean debug = Boolean.parseBoolean(enableDebug); but this is legacy code. However, it may have seemed too much work to actually pass in a String, and the code needed debugging all the time anyway... Changing it to: boolean debug = Boolean.TRUE; would lose the place holder for where to put in a String indicating whether debug is enabled. Incidentally, in code written this way, I would treat turning debug off as a separate, hopefully small, project in its own right, to be done after you have revision control and regression testing in place. There is a risk that functionally necessary code is being executed only if debug is true, and that the debug false paths are under-tested. Patricia > ...> boolean debug = Boolean.valueOf("true").booleanValue(); > [quoted text clipped - 31 lines] > > Patricia Ms Patricia, I respect a person like you who know the reality of the trench. Code can become any-kind dirty through quick'n dirty revisions. > ... >> boolean debug = Boolean.valueOf("true").booleanValue(); > ... > > That sort of thing can arise due to a series of changes, combined with a > possible intent to change back. Heh. The voice of a real, experienced expert!! BugBear >Here's today's sample: > >boolean debug = Boolean.valueOf("true").booleanValue(); See http://mindprod.com/jgloss/unmain.html for what he may be up to. SignatureRoedy Green Canadian Mind Products The Java Glossary http://mindprod.com > So I've been working at a company that shall remain unnamed for the > time being for almost 3 months now. In that time, I've taken over for [quoted text clipped - 21 lines] > > WTF WTF WTF WTF WTF!!!!!!! that might be decompiled code > I was warned that the legacy stuff can be rather tough to get a handle > on right away. Boy, was that an understatement. I can understand [quoted text clipped - 12 lines] > > boolean debug = Boolean.valueOf("true").booleanValue(); :-) If you have a team of let us say 20 developers, then there will be a blend of skills: some will be good, some will be average and some will be not so good. Even good programmers have bad days. They have hangovers after drinking to 4AM or they had a horrible argument with their wife or there are serious illness in the family etc.etc.. Sometimes some really bizarre code is produced. And it is as natural as that the weather sometimes is bad. When you have 20 years of experience, then nothing will surprise you. Arne > I was warned that the legacy stuff can be rather tough to get a handle > on right away. Boy, was that an understatement. I can understand Try working on a 20+ year old project with code that has roots going back almost 50 years that has been rewritten from language to language and ported from one platform to the next over the decades.... I know one guy who can write FORTRAN in *any* language. - Kurt > > I was warned that the legacy stuff can be rather tough to get a handle > > on right away. Boy, was that an understatement. I can understand [quoted text clipped - 4 lines] > > I know one guy who can write FORTRAN in *any* language. It's the ones that can write COBOL in any language that worry me. And the rare one that can write perl in any language is downright scary. I've also seen C++ code written in C (everything is bristling with hooks like velcro, and there are several structs full of nothing but function pointers), and of course there's the occasional wackjob that codes Java, Ruby, or Eiffel that looks suspiciously like BASIC. Sometimes with //100, //110, //120 at the end of every line. It's always worst when the target language is C, because of the preprocessor. No, it's second worst; worst is C++. Macros to "dim" an array; #define BEGIN { and #define END } are almost staples; one nut had a blank #define GOSUB and stuck GOSUB just before every freaking function call. And of course no matter what ancient cruft they used to code in there's one thing they still have in C++ that they just loooove ... goto. Thank Christ Java frustrates their goto and macro fetishes; the worst of them seem to avoid Java jobs like the plague, and all I have to put up with there is spaghetti class dependencies (I think this comes from certain pure-OO or pure-functional types), no class dependencies at all (almost any procedural background), convoluted method code (either, or FORTRAN), simple repetitive method code that is verbose and eschews most higher forms of control structure (FORTRAN or COBOL), tons of over-general types (especially foobar (Object this, Object that, Object theother) throws Exception) and anonymous inner classes and tangled flow paths with tons of method calls and very little procedure at all (aha, a Smalltalker!), and everyone's favorite since Java 5 came out, spaghetti type parameter dependencies like Foo<X extends Y> extends Bar<Y, Z extends Quux, Foo, P super Quux && extends Mumble<S extends SeriouslyFUBAR<String>>>. The worst offenders here? Ex-C++ coders of course... Lately we're even seeing in this newsgroup a surge of people using Java 6 regular expression stuff to do just about everything. Integer.parseInt()? Never heard of it. DateFormat? Couldn't give a sh.t. The existing XML-parsing feeping creature lurking in the SAX part of the standard library? Where the f.ck is the fun in that -- time to roll our own! Who needs any of these when we can probably make turing complete code out of nothing but calls to Pattern and Matcher and a whole lot of string literals that look like line noise! I think the vanguard of the invasion of the folks who can write perl in any language has arrived in Javaland ... > Lately we're even seeing in this newsgroup a surge of people using > Java 6 regular expression stuff to do just about everything. [quoted text clipped - 7 lines] > I think the vanguard of the invasion of the folks who can write perl > in any language has arrived in Javaland ... Nice rant! But, to be sure, applying regexp's is better than just another 3+ page spaghetti method with lots of references to String#charAt and the like. Just because 90% of the java community is too ... hmmm, mentally different? ... to understand regular expressions doesn't mean they are a bad thing. Ingo Menger wrote : > Just because 90% of the java community is too ... hmmm, mentally > different? ... to understand regular expressions doesn't mean they are > a bad thing. My, that is a broad brush you are using... I have learned over 15 languages over my career. Both by self-learning and formal courses. Not to mention mark-up syntax (*ML). I do use regex, where it is appropriate. The more languages and methodologies you know, the better you can determine the right one for THIS job. And each language has some sort of unique way of "doing things" which can be applied elsewhere. SignatureWojtek :-) The worst code I ever had to work on was something that was ported from ASM to C, to C++ and then to Java. Ugh. Obviously, management told the developers not to rewrite, but to port, because it was "cheaper and faster". Yeah, right, if you can't see past the end of your own nose. Still, my vote for all-time brain-dead code goes like this: if( a > b ) { return true; } else { return false; } I see that all the time, instead of simply return a > b; > Still, my vote for all-time brain-dead code goes like this: > if( a > b ) { > return true; [quoted text clipped - 5 lines] > > return a > b; Most of these things come into existence after optimzation. Imagine that someone had computations in one of the clauses that later got washed away. If you then don't optimize it to the end, such clauses tend to remain. My favorite was a=1; Assert(a==1); if (a==1) { ... } This must also have gone through some "optimization" when lines in between got washed away. At the time we were writing high-availability software so we had a few laughs on this over-zealous code. Michael >Still, my vote for all-time brain-dead code goes like this: > [quoted text clipped - 3 lines] > return false; >} This can easily arise from a desire to set breakpoints in one of the cases without having to mess around with conditional breakpoints (if the debugger even supports that). Cheers Bent D SignatureBent Dalager - bcd@pvv.org - http://www.pvv.org/~bcd powered by emacs >> Still, my vote for all-time brain-dead code goes like this: >> [quoted text clipped - 7 lines] > cases without having to mess around with conditional breakpoints (if > the debugger even supports that). Not as clean as: boolean forBreakpoint = (a > b); return forBreakpoint; And if their debugger doesn't support conditional breakpoints, they can switch to either Eclipse or NetBeans for the right price. SignatureLew >>> Still, my vote for all-time brain-dead code goes like this: >>> [quoted text clipped - 12 lines] > boolean forBreakpoint = (a > b); > return forBreakpoint; That doesn't let you break only on true (or only on false). > And if their debugger doesn't support conditional breakpoints, they > can switch to either Eclipse or NetBeans for the right price. That's true only if you meaure cost solely by initial cash outlay. Even if Eclipse or NetBreans will eventually be as productive as their current debugger, there's the learning curve to consider. And then there's the fact that conditional breakpoints can be annoyingly slow. .If I want to break only on false, and false occurs once every 10,000 times through the code, it can take much longer for the debugger to get control 10,000 times, evaluating my expression each time, and relinquishing control back 9,999 times, than for the debugger to get control only once. >And if their debugger doesn't support conditional breakpoints, they can switch >to either Eclipse or NetBeans for the right price. I tend to avoid conditional breakpoints even when they are supported. I like the simplicity of "if the line is red, the debugger will break there" over "if the line is red, the debugger may stop there sometimes and maybe I even got the conditional right". Cheers Bent D SignatureBent Dalager - bcd@pvv.org - http://www.pvv.org/~bcd powered by emacs >>Still, my vote for all-time brain-dead code goes like this: >> [quoted text clipped - 7 lines] > cases without having to mess around with conditional breakpoints (if > the debugger even supports that). Ok, I'll give them the benefit of the doubt, but based on my own experience, I think a legitimate use of that idiom is relatively rare in practice. >> Still, my vote for all-time brain-dead code goes like this: >> [quoted text clipped - 7 lines] > cases without having to mess around with conditional breakpoints (if > the debugger even supports that). Or logging. BugBear >> Still, my vote for all-time brain-dead code goes like this: >> [quoted text clipped - 7 lines] > cases without having to mess around with conditional breakpoints (if > the debugger even supports that). It also helps logging. BugBear > >> Still, my vote for all-time brain-dead code goes like this: > [quoted text clipped - 11 lines] > > BugBear Do you see anything in that code that even is capable under the JLS of having side effects, such as logging? I only see an if statement, a return statement, a > operator expression (which in current Java cannot be overloaded to have side effects), and boolean literals. :P >>>> Still, my vote for all-time brain-dead code goes like this: >> [quoted text clipped - 16 lines] > return statement, a > operator expression (which in current Java > cannot be overloaded to have side effects), and boolean literals. :P But it was loaded by a class.loader set up to recognize and instrument if-then-else constructs with calls to a logger :-) On Jul 31, 1:52 am, "Mike Schilling" <mscottschill...@hotmail.com> wrote: > But it was loaded by a class.loader set up to recognize and instrument > if-then-else constructs with calls to a logger :-) A contrived, Rube-Goldbergian example. And if you're doing that, why not have it log any occasion where a nonliteral boolean-valued expression is evaluated? (Cue even more contrived, Rube-Goldbergian example.) > On Jul 31, 1:52 am, "Mike Schilling" <mscottschill...@hotmail.com> > wrote: [quoted text clipped - 4 lines] > not have it log any occasion where a nonliteral boolean-valued > expression is evaluated? Now you're just being silly. On Jul 31, 2:28 am, "Mike Schilling" <mscottschill...@hotmail.com> wrote: > Now you're just being silly. He's good at that. =P Twisted - given that we're talking about examples of fairly ugly code and looking at possible reasons for it, don't you think it's fair to consider fairly ugly reasons, along with good ones? They may not actually justify the ugliness, but it could make the ugliness more understandable/forgivable. >>>>> Still, my vote for all-time brain-dead code goes like this: >>>>> if( a > b ) { [quoted text clipped - 15 lines] > But it was loaded by a class.loader set up to recognize and instrument > if-then-else constructs with calls to a logger :-) There is no significant difference in generated bytecode between the code quoted above, and the "clever" alternative. For example, compile the following simple class: public class DetectIfThenElse { public static boolean sillyCheck(int a, int b) { if( a > b ) { return true; } else { return false; } } public static boolean cleverCheck(int a, int b) { return a > b; } } And then, run javap run with -c option on the bytecode generated by the compiler. The result printed out in my environment is: Compiled from "DetectIfThenElse.java" public class DetectIfThenElse extends java.lang.Object{ public DetectIfThenElse(); Code: 0: aload_0 1: invokespecial #8; //Method java/lang/Object."<init>":()V 4: return public static boolean sillyCheck(int, int); Code: 0: iload_0 1: iload_1 2: if_icmple 7 5: iconst_1 6: ireturn 7: iconst_0 8: ireturn public static boolean cleverCheck(int, int); Code: 0: iload_0 1: iload_1 2: if_icmple 7 5: iconst_1 6: ireturn 7: iconst_0 8: ireturn } Having the above example, how would the instrumenting code distinguish, which method uses the "if-then-else" construct? piotr >>>>>> Still, my vote for all-time brain-dead code goes like this: >>>>>> if( a > b ) { [quoted text clipped - 73 lines] > Having the above example, how would the instrumenting code distinguish, > which method uses the "if-then-else" construct? Therefore, use the "clever" alternative because the "silly" one offers no advantage, and the "clever" one is better at the source-code level. Since we generally don't look at the bytecode, the cleaner source code must win. SignatureLew >>>> Still, my vote for all-time brain-dead code goes like this: >>>> if( a > b ) { [quoted text clipped - 13 lines] > return statement, a > operator expression (which in current Java > cannot be overloaded to have side effects), and boolean literals. :P I didn't say such a coding structure DID logging, I said it HELPS logging. To expand, one could put a logging statement in the "true" path. Adding such (conditional) logging to the more compact versions is less convenient. BugBear > boolean debug = Boolean.valueOf("true").booleanValue(); Code like this would be eliminated by a code review so it follows that code is being checked in without a code review, even for small changes. I would start doing more code reviews to eliminate bugs before testing picks it up in the next build or worse yet, a customer finds it in the next release. SignatureTris Orendorff [Q: What kind of modem did Jimi Hendrix use? A: A purple Hayes.] >> boolean debug = Boolean.valueOf("true").booleanValue(); > [quoted text clipped - 3 lines] > before testing picks it up in the next build or worse yet, a customer > finds it in the next release. The OP said "When I got here, there was no version control in use whatsoever.". In that situation I would use the best known code, unmodified, as the base revision. Yes, that involves checking-in unreviewed code with nasty stuff in it, but I would not want to even start the clean-up process without version control. Patricia > The OP said "When I got here, there was no version control in use > whatsoever.". Oops! Missed that. > In that situation I would use the best known code, unmodified, as the > base revision. Yes, that involves checking-in unreviewed code with nasty > stuff in it, but I would not want to even start the clean-up process > without version control. Agreed! Also, if there's no version control or code review, there's a 99% chance of haivng no automated unit tests either. I'd be very wary about touching that code without a good reason. SignatureTris Orendorff [Q: What kind of modem did Jimi Hendrix use? A: A purple Hayes.] >> The OP said "When I got here, there was no version control in use >> whatsoever.". [quoted text clipped - 9 lines] > a 99% chance of haivng no automated unit tests either. I'd be very > wary about touching that code without a good reason. The ugliest part of a situation like this is not knowing whuch version of the source is actually running. Java makes this a bit easier, since you can decompile the running .classes and compare them to the possible source files. (Unless they've been obfuscated, of course. In that case, say that you're going out to get coffee and never come back.) Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.