81–90 of 136 posts
Maybe with proper code review these kinds of ridiculous problems would get caught early and stomped on rather than turning into actual problems.
Yes, I already know your first answer: "Switch jobs".
Earlier quoted context omitted.
Unless there is a lot of creative abuse of operator overloading or macros lurking in there that code really doesn't look too awful compared to some monstrosities I've had to work with.
I agree. At first glance, I thought that the NbrofA/AA/etc names were just gibberish. The most nonsensical part to me is starting the for-loop iterator at zero, and then only executing the function if the iterator is non-zero.
I worked with a guy (I won't name the company) who wrote Java code in one, huge, static class as much as possible. In fact, everything was largely in one function too. He decided to name his fields alphabetically. static int a static int b static String c static float d static int e... What, I wondered, would happen when he ran out of letters? Scrolling down further I saw this: static int aa static float ab static St…
To really bork up the Java, you need a pattern fanatic. Once you stand working with Handler Adapter Handlers you know you should have taken the other colour pill.
-- after HL Menkin
I decided to test this assertion.
The program in question was trivial - it was one of those contrived examples of how OOP works, a "Kennel" which had "Dog" objects which possessed various traits, and would bark() or wag(), stuff like that.
I obfuscated the code as much as I could - indentation all over the place, line breaks in inappropriate places, code hidden inside multi-line comments, and multiple dummy variables named one character off from the useful variables. The useful variables had names like "satrtrek," "maryppopins" and "pizza." The dummies were "startrek" and "marypoppins."
This exercise taught me nothing about writing code, but because my code gave the expected output, I still got an A. Source code comments from then on were made only as needed.
The next semester, I got an email from a friend of mine who just couldn't get his head around what was supposed to be going on. He asked whether I'd kept the source to one particular program, so that he could review it and see if he couldn't make sense of the assignment.
I had indeed kept it, and just sent the .java files to him without opening them for review. By coincidence, the program he was stuck on was the one I'd obfuscated. He switched his major to Math and Spanish for what I believe to be unrelated reasons.
This is off topic but I find it difficult to read the blog-articles from jaquesmattheij.com . Zooming doesn't help because the text doesn't wrap correctly. Just a suggestion for the author to change the layout of the page.
The typography is off. The body text is written in Arial, which is not a great choice for body text (it's better for display). When in doubt, use Verdana (sans-serif) or Georgia (serif) for body text. Also, the font size is too small. Here is an example of his blog with better typography. I used 18px Georgia as the body text instead of 12px Arial. I used Droid Sans (a nice display font) for the blog title. http://i.i…
You really don't know bad programming until you have spent some time in a 50000 line cobol program. I'd post some crap I work on every day but I don't want to make anyone cry. Nevermind. Here's some random code I'm working on. MOVE SPACES TO LISTBAT-NAME. STRING WORK-FILES "LIST.BAT" DELIMITED BY " " INTO LISTBAT-NAME. OPEN OUTPUT LISTBAT. MOVE SPACES TO SCR-S. STRING "DIR /B " DATA-PREFIX " > " WORK-FILES "TMPLIST"…
Maybe with proper code review these kinds of ridiculous problems would get caught early and stomped on rather than turning into actual problems.
Honest question - how does code review work among "peers" with no seniority. Hypothetically speaking snicker say one peer likes to churn out reams of nonsense code and the other peer is looking forward to a sense of maintainability. Yes, I already know your first answer: "Switch jobs".
If he's simply lazy or doesn't care... Well, all you can do is go through the pockets and look for loose change. No amount of "process" can make a bad employee into a good one.
Maybe with proper code review these kinds of ridiculous problems would get caught early and stomped on rather than turning into actual problems.
Honest question - how does code review work among "peers" with no seniority. Hypothetically speaking snicker say one peer likes to churn out reams of nonsense code and the other peer is looking forward to a sense of maintainability. Yes, I already know your first answer: "Switch jobs".