Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×
It's funny.  Laugh.

How To Write Unmaintainable Code 327

/ writes "Roedy Green of Canadian Mind Products has written an essay entitled "How To Write Unmaintainable Code". Following his 54 tips, you too can guarantee job-security by becoming irreplaceable. If that weren't good enough, it's even available in Spanish. "
This discussion has been archived. No new comments can be posted.

How To Write Unmaintainable Code

Comments Filter:
  • as a cs student, nothing inspires me more! job security rules!
  • I worked at the same web shop for 3 years while in college.
    What started off as a no pay internship turned into a $60/hour job, mainly because my code was valuable and it would have been impossible for someone else to figure out what I did and how it worked.
    Every time I mentioned other job offers, they just raised what they were paying me. It would have taken months for some fool to understand my code and do anything useful with it.
    I decided to continue in grad. school and I feel kinda bad leaving them with an expensive mess of spaghetti. If they pay $100/hour I'll spend my winter break making it understandable.
  • I don't know if its funny or scary. Ya job security is a nice thing, but come on people write decent code.

  • The funniest one, by far, I thought, was: Make sure that every method does a little bit more (or less) than its name suggests. As a simple example, a method named isValid(x) should as a side effect convert x to binary and store the result in a database.

    That had be laughing outloud! Being a web developer, I have often had to work with code that tried to do many, many thing. One web page would try to accomplish thirty different things, based solely upon the querystring parameters passed in. Ugh. Now there's job security! :)

  • by E-TiE ( 107831 ) on Thursday November 18, 1999 @05:51PM (#1520483)
    Writing unmaintainable code for job security is a Bad Idea (TM). Cuz guess what? You might end up the victim of your own practices -- and who's going to get fired when they've failed to figure out code they wrote a year ago? You. Don't do it. Maye you should work somewhere else where they know how much you're important and valuable to them, so you don't have to take such measures as to write bad code. And if you're going to get replaced so easily then maybe you were not worth your salt in the first place.
    ------------------------------------------ -----
  • Huh, that brings up an interesting point. What is better, to write crappy code or to take the time to make it nice and neat? From the programmer's perspective, it makes sense to write crappy code: bosses are demanding you finish projects before you even begin them, and good takes time to write; also, like you mentioned, job security is nice indeed.

    However, don't we, as programmers, have some sort of obligation to try our best to create nice, maintainable code? I may be getting a little too philosophical here, but we expect artists to paint to their best abilities, poets to write to their best ability. It seems like if someone in one of these professions purposefully wrote sloppy poetry, or half-assed a painting, that we would look down on them. Perhaps it is a pride thing, but you think you'd intrinsically want to write good code.

    I am not trying to sound preachy, CFN, for I don't know if you wrote sloppy code because you wanted to, or, more likely, because you were rushed and your superiors favored quantity of quality.

  • He forgot one of my personal favorites. Make the code look like it isn't code. Such as

    for(int i =0; i-->;)

    in Java, C or C++.

    Bad Command Or File Name
  • I tried to write unmaintainable, obfuscated code that would make be irreplaceable, but I failed. Do you think it had anything to do with my using Python? :)
  • Checking out messy code after a few months with no documentation, I can't even understand my own damn code! That like, sucks and stuff.

  • by Pfhreakaz0id ( 82141 ) on Thursday November 18, 1999 @05:55PM (#1520488)

    I Quote from the essay .... Maintenance programmers, if somebody ever consulted them, would demand ways to hide the housekeeping details so they could see the forest for the trees. They would demand all sorts of shortcuts so they would not have to type so much and so they could see more of the program at once on the screen. They would complain loudly about the myriad petty time-wasting tasks the compilers demand of them.

    This is precisely the reason VB is so popular for business apps. You have to really work hard to confuse matters sufficiently in a VB program so that a decent maintenance programmer can't figure it out.... although I could write my own list applicicable to Vb for my current project... My favorite: Make sure you have the same variable name to reference a database in several different classes in several different programs, but have it point to three different databases depending on which variable is in scope currently :)

  • by Anonymous Coward on Thursday November 18, 1999 @05:57PM (#1520489)
    To write unmaintainable code is a very unworthwhile thing to do, because you will be essentially married to the code until you find somebody to which you can explain it.

    Personally once I write some code I want it to be maintainable enough so other people can contibute for I can move on with other things. I do not feel that my life consists of solely maintaining code, why not do something challenging? Rather then babysitting one of my past accomplishments. Why not take over the world?

  • by torpor ( 458 ) <> on Thursday November 18, 1999 @05:57PM (#1520490) Homepage Journal
    Back in the good old days of DOS (and thus, 80x25 page size), I had a programmer in my team who followed the "all functions must fit on one page" rule...

    Man, the number of times I wanted to kill that guy. We called him Anti-Whitespace.

    Scarey though, how that page gave guidelines that I myself have been guilty of following too many times in the past. Is there a counter-page to that one, that gives guidelines (general purpose) that make it easier to work with other programmers?

  • I would have to agree, you got to be absolute braindead to write unreadable vb code. For the most part good vb coders can write some great code then performs well. The problem is everybody and their grandma can write vb, this is where vb gets its piss poor performance. I would still write C dll's for the hard core crunching.

  • My code was a victim of constantly expanding project definition (CEPD).
    It was impossible to keep it nice b/c new features were requested so we could demo to some client, etc.
    Mgmt. was more concerned with showing it off that having it built soundly and they got what they paid for.
    It actually could have been nice, but whenever they felt I was "idle" (i.e. not showing them a new feature every 2nd day, but fixing what was behind the sceens) they would find a new feature to add or have me work on some other project.
  • by twit ( 60210 ) on Thursday November 18, 1999 @06:02PM (#1520494) Homepage
    I hate it when members of my team write unmaintainable code. Frequently, when time's short or when people need help, I have to dive in, and I've found it difficult to get my bearings in code that I did the initial design for - difficult to see the forest for the trees, even when I planned out the forest.

    Good practises in programming isn't just for academics; it's the epitome of professional code writing. A manager once tried to draw the definition of a hack and a real programmer by the completeness and bug-free state of their code. I think he's wrong. I think that a real hack writes code that no one can pick up. A real programmer writes code that anyone can pick up and fix or expand - whether it's complete at any one point or not.

  • Well if you are developing for an Open Source project then your code must be readable, but when you develop for a one time shot product and you hate the PM, then coders tend to stray off, just for spite.

  • by prok ( 8502 )
    All you gotta do is write it in perl...
  • The stuff at the end about coding environments is very similar to what I have heard Smalltalkers describe as how a good Smalltalk environment works.

    And of course anyone who wants to avoid accidentally using a few of those practices could be worse advised than to buy, read, and apply the concepts in a copy of Code Complete...

  • by eldurbarn ( 111734 ) on Thursday November 18, 1999 @06:09PM (#1520499)
    The first n years of my career were spent maintaining old code. Assembler. I vowed "I will write maintainable code".

    Now I write good code. Maintainable. Well commented. Meaningful variable names. Nothing fancy. I know what it's like to revisit my code ten years later.

    There is a problem, though.

    Nobody else seems able to maintain my code. They just can't understand it.

    Despite high-level pseudo-code algorithm descriptions, threaded comments, good up to date written documentation, they just can't wrap their tiny little heads around how I do things.

    I can go back to something I wrote 15 years ago and fix problems without generating new ones. My code is robust enought that I can shovel out a few thousand lines and jam in another 10,000 lines, test it for a day or two and release it... and get no bug reports for another 5 years. I consider this to be maintainable code!

    Go ahead... break all the rules suggested in the article. You may still produce code that other, lesser programmers simply can't cope with. The code is an expression from the mind of the person who wrote it... and sometimes writing to the lowest common denominator simply isn't possible.

    And then they blame you for writing unmaintainable code.

  • Is there a counter-page to that one, that gives guidelines (general purpose) that make it easier to work with other programmers?

    Unless I'm very mistaken, that's a Johnny Don't list. As in, "Don't do what Johnny Don't does". (Non-native English readers: "&$thing unless $johnny_dont->can($thing);".) If you don't do the things on the list, you won't have unreadable code.

  • by Signal 11 ( 7608 )
    Bah, I can tell you to do it much easier than that - use BASIC. >:)
  • Only one Microsoft joke so far? :) ouch, slashdot is slipping
  • What sense does that make? If a company wanted to fire an individual he probably sucked anyway! I mean, the market is flooded so much that there are currently more jobs than people around to fill them. So, if you are being fired - then you truly ARE a dumbass. Furthermore, imagine u got promoted (it happens), and then you had to deal with someone who fuq'd with their code so that no one can do anything with it. You would be screwed years of work and money. I dunno, jus way i feel. Ill stop now.
  • Cute, but if I read it correctly it'll fall through right away without executing the next line. What's the point in that?
  • by UnknownSoldier ( 67820 ) on Thursday November 18, 1999 @06:25PM (#1520508)
    It's not a philosohpical issue, it's one of practicality:

    When (not if) you end up maintaining someone else's code, if the code has been written in a clean way, it can be a sure joy to work with. If not, you'll be cursing that programmer for eons.
    (Lets keep Microsoft's API out of this ok ;-)

    The REASON we want good clean code is so that _we CAN_ maintain it.

    I have been in the position of looking at my own code 6 months, later, and gone "WTF?", and wasted lots of time trying to figure out just what the heck I did.

    If I had just spent the extra time to begin with, later on I could of been more productive instead of wasting time re-engineering the damn thing.

    Pay the piper up front and save time later, or be a "saving time" grinch, and find an expensive time bill later. Seems pretty obvious what "The Right Thing" to do is ;-)

    Work smarter, not harder =P


    BTW, Steve McConnel has a great book: Code Complete.
  • Unreadable Python is tough but can be done. See the standard turtle module; xmllib shows what can be accomplished through proper use of regexps.

    Many of the rules he mentions can be applied; just because your first block used one indent doesn't mean the second block (at the same level) need use the same indent. The "open list" line continuation trick can be good for some real horrors with some care.

    Of course if you're willing to work at it you can do things like this:

    from sys import*;from string \ import*;a=argv;[s,p,q]=filter(lambda x:x[:1]!=
    '-',a);d='-d'in \ a;e,n=atol(p,16),atol(q,16);l=(len(q)+1)/2;o,inb=l -d,l-1+d
    while;s and \ map(stdout.write,map(lambda i,b=pow(reduce(
    lambda \ x,y:(x>8*i&255),range(o-1,-1,-1)))

    (\ denotes form induced breaks not present in the original; should be 4 lines total).

    Extra point if you can figure that one out and/or name the source I've shamelessly stolen it from.
  • Hmmm... I definately wouldn't sacrifice whitespace to make a function fit on one page. But I am a fan of making object's methods fit on a screen or 2 (well, at high res at least) and never having an if's else more than a screen away if at all possible.
  • Byte had a feature [] entitled: "How to Fail at Software Development, Don't Communicate" it at a slightly higher level, but is just as useful.
  • why not write the code in perl such that when the program starts it reads the code in and then executes from refrence to subs?

    (i've actually done that, and i understand what i do in my own code, but i'd like to see somebody else try to explain it :)

    i seriously hope this page was intended as a joke
  • That is right. If you set out to do it in a sane way from the beginning you will very likely get the same task done more quickly than if you just hack out something on the fly and try to make it work. The maintainability and lower bug rate is a bonus on top of that.

  • by eldurbarn ( 111734 ) on Thursday November 18, 1999 @06:34PM (#1520516)
    We had a system with about 750,000 lines of assembler, doing some heavy-duty, real-time math modeling of oceans. The hardware was old. The contractor said they'd deliver a modern system with the code in C.

    They wrote a converter that digested the assembler and produced C code... about 4 lines of C for each line of assembler code.

    So a math calculation that could easily be written in 1 line of C took 30 or 40 lines of assembler which converted into 120+ lines of C. (Stop screaming!)

    Their converter did not put the original source line as a comment in the new source. (Now you may scream!)

    Now I gotta maintain this pile of compost. I'm looking for another job.

  • by mmmmbeer ( 107215 ) on Thursday November 18, 1999 @06:34PM (#1520517)
    In naming functions, make heavy use of abstract words like it, everything, data, handle, stuff, do, routine, perform and the digits e.g. routineX48, PerformDataFunction, DoIt, HandleStuff and do_args_method.

    He forgot "Thingy"! How can you forget "Thingy"? As in "Take the thingy passed in by the user, send it through the thingy, and return the thingy to the user" and "Merge the two thingies, extract the resultant thingy, discard the other thingy, you don't need it here, and then pass the thingy on to the next thingy."
  • I'm amused by how many posts here actually took this article seriously, seeing that it came from the "It's funny. Laugh." department. I suppose the phrase "It's funny. Laugh." should be taken in the imperative? :-)

  • Looked great in preview, screwed when posted. The important flaw is on the last line; I think I can get this one right:

    lambda x,y:(x<<8L)+y,map(ord,s)),e,n):chr(b>>8*i&255),ran ge(o-1,-1,-1)))

    If you want to post <(&lt;) or >(&gt;) note that the preview form converts the char entities back to characters, and double check 'em.
  • 24. Never document the units of measure of any variable, input, output or parameter. e.g. feet, metres, cartons. This is not so important in bean counting, but it is very important in engineering work. As a corollary, never document the units of measure of any conversion constants, or how the values were derived. It is mild cheating, but very effective, to salt the code with some incorrect units of measure in the comments. If you are feeling particularly malicious, make up your own unit of measure; name it after yourself or some obscure person and never define it. If somebody challenges you, tell them you did so that you could use integer rather than floating point arithmetic.

    Looks like some Lockheed employee took this page too seriously.

    (numbering might be wrong because i got it from the googlecache [] version, which has only 53 rules.
  • by TummyX ( 84871 ) on Thursday November 18, 1999 @06:46PM (#1520521)

    Ignore the conventions in Java for where to use upper case in variable and class names i.e. Classes start with upper case, variables with lower case, constants are all upper case, with internal words capitalised. After all, Sun does (e.g. instanceof vs isInstanceOf, Hashtable). Not to worry, the compiler won't even issue a warning to give you away. If your boss forces you to use the conventions, when there is any doubt about whether an internal word should be capitalised, avoid capitalising or make a random choice, e.g. use both inputFileName and outputfilename. You can of course drive your team members insane by inventing your own insanely complex naming conventions then berate others for not following them. The ultimate technique is to create as many variable names as possible that differ subtlely from each other only in case.

    (e.g. instanceof vs isInstanceOf, Hashtable)

    they are all valid w.r.t the conventions.

    instanceof is an operator and a keyword hence should be all lowercase, isInstanceOf is a method name, hence should start with a lower case character and the rest of the words should be capatilized, and Hashtable is a class name hence every word should start with a capital. Hashtable is the only one you could argue, but I'd say that sun just think Hashtable is one compounded word in itself not two words that describe a class's function.
  • That's because we have none of their awful code to look at!
  • Wow! You are the perfect programmer. Surely I can download and read some of this fault-free code! Joy of joys, tonight I have a new idol! URLs, please.

  • by Raul Acevedo ( 15878 ) <raul@c[ ] ['ant' in gap]> on Thursday November 18, 1999 @06:49PM (#1520524) Homepage
    WARNING: 20 years of looking at, fixing and replacing bad code about to be vented...
    • Put all your code into a single function. (I've seen functions over 2000 lines in length.) After all, those nasty functions generate overhead on each call, and you want your code to be efficient right?

    • Use hungarian notation for variables. Then instead of the overly verbose

      int numLinePayments; char *maxTypeCode;
      you have the nice and compact

      int iNmPt; char *szTyC;

      BONUS: With compact hungarian notation, you can become even more descriptive! So really the above becomes:

      int iLnNmMtCsByPt; char *szMxQtBlTyAcC;
      So much more descriptive information, all in the same amount of space. I've been on projects using this, and the sheer of joy of it cannot be accurately described in words.

    • Don't indent your code uniformly. (This is a variation on #11 from the article.) Use Windoze or vi editors, with non-standard tab widths, for tabbing and indenting, which means that no one can see your code indented properly unless they use the same tools you use, with your same editing configuration.

      BONUS: Write extremely long lines of code, well over 80 characters per line.

    • If using C or C++, don't use memory analysis tools like Purify [], or its open source equivalents. After all, if you find your bugs too quickly, you might lose your job.

    • On large projects with several programmers, make sure you change global header files that cause everybody else's code to break but yours. Do this late in the afternoon, so all hell breaks loose breaks right before people are going home, or late at night, so that everybody comes in fresh the next morning and wonders what the hell happened to the code that compiled perfectly when they left the day before. Either way, make sure you are not around when they find out! Otherwise you spare them the joy of figuring out what you changed, and why.

      BONUS: Do this right before a major deadline.

    • Do really stupid stuff that you were taught from day 1 not to do, but everyone seems to do anyway: don't check for NULL, fix array sizes where you hardcode the max size everywhere, don't check for invalid or oversized input, etc.

    • Use preprocessor macros. Lots of them. (I was actually on a project where someone suggested using cpp to define macros. For Java. Absolutely brilliant!) The key is to use a single macro for multiple statements, in effect using macros as function calls. Example:

      #define DO_STUFF(x,y,z) if (x else more_stuff(z); \
      mystery(a*2, z-1); \
      for (int n = x; x != foo; x--) \
      more_stuff(n - x);
      Notice the "hidden" use of external variables and functions. Remember, you want to avoid those expensive subroutine calls! And think of the joys of setting breakpoints and stepping through a debugger on that code!

      BONUS: Don't use the all uppercase convention in macro names; use the same naming convention as function calls. It's even more fun to debug when you have to spend time actually figuring out do_stuff() isn't even a function call!

      MORE BONUS: Nest macro calls. Use the naming convention above.

      EVEN MORE BONUS: Use macro calls as variables. Make sure the expanded macro makes function calls. Or uses other macros.

    • Don't use source code control. Or, use it, but never unlock or checkin your files. Feel free to steal locks on others, though.
    And finally, one of my favorites, for all the young and aspiring hacker types out there:
    • Write code only for yourself. Assume no one will ever need to figure out how to use your code without poring through it in painstaking detail. Do not make it easy to use, interface with other code, or even compile. Include 30 caveats that would take you only a few minutes to fix, but you're just too lazy to. In other words, write as if no one will every look at or use your code, yet release it to everyone to look at and use. Defend your laziness, which is causing thousands of lost hours of work to others, by uttering useless and stupid "cool hacker" mantras like "Real Programmers don't write documentation" and "If it was hard to write, it should be hard to understand."
    Phew. That little tirade made me feel good. :)
  • Ditto that... It's full :(. Ironically, I'd consider mirroring it myself, but I can't get in ;).

    Alex Bischoff

  • That "rule" is actually a good one. Except it should be more of a guideline, than a strict rule. The idea is a good one, which is to keep code in logical, relatively small and coherent modules. Going overboard to forcing it to exactly 25 lines (or any exact number), for all code, is bad.
  • by augustz ( 18082 ) on Thursday November 18, 1999 @06:54PM (#1520528) Homepage
    Mirrored here []


  • Mirrored here []

    Enjoy this

  • I miss-typed that url... Sorry...
  • Ah yes, how to make prefectly usable code look like line noise in one easy to use language :)


  • The best way to maintain job security is to have legacy code written in an out-dated programming language. And as far as obscure coding goes, what is better than writing in a language that is no longer taught to the kiddies that may take your job away.

    You may laugh at this. I don't. We have a Fortran programmer that wrote a lot of legacy production code (for the Vax). I know fortran (at least up to fortran77) although I haven't written in this language for a long time. Some of the younger ppl trying to port the code to newer systems have had a miserable time. But, hey, no problem! This guy is going to port his code to run on a unix system and will rewrite in C. No wait, he decides that he will skip c and rewrite the code in a new language that he hears is all the rage; c++. Two years go by.

    He gives up learning c++ and ports his code to c. Another two years go by. If you know fortran, then you know that character manipulation is a bitch. I check his code and realize that he does not know the rudimentary aspect of c. He has essentially rewritten the function atoi. yikes.

    On a side note: Obscure variable names is nothing new. Take a look at old fortran code written for a system with a 8 character limit.

    On another side note: Many, many moons ago in my 1st computer class (fortran), I wrote a program that used the variable names kitty, cat, meow, and woof. Kitty was the integer equivalent to cat, and meow was the integer equivalent to woof. The prof was not pleased despite my explanation of the brilliance of my choice of variable names.:)

  • I don't know what you're smoking, but that doesn't just look like it isn't code: it isn't code.

    At least it's not C code.

    You can't declare variables inside of a for statement, and even if you could, I've no idea what i--> is supposed to parse as.

  • Artists and poets are usually not replaced on a whim because of a "cheaper" alternative (young college puke) comes around.
  • by Anonymous Coward on Thursday November 18, 1999 @07:02PM (#1520535)
    Oh dear, oh dear ...

    My company (owned by me) started a small contract last month at "a small financial services company" (let's not be too specific). About two years ago, they started to migrate off of DOS, a small 3090, and some netware boxes to Solaris. In the meantime, their workload has been growing. The old mainframers decided that they didn't like UNIX and waged a two year war to get rid of UNIX. All the UNIX guys left. Then they bought out two larger (but apparently worse-run) companies that were run completely on, you guessed it, UNIX. The mainframers announced that they were old and tired and perhaps they should bring the UNIX guys back (they were apparently told that they didn't have a choice). But they wouldn't come back (lots of work in Dallas for good UNIX guys, without rabid mainframers in the next cube). For the last nine months or so, they have had one group of "Unix" "consultants" from most of the majors over there "trying to fix the code" that they inherited. The code? perl. Just perl. A little ksh junk, some C, mostly perl.

    I (and two other people) are now 10% done (we estimate, and we are usually right on estimates). None of us can figure out what was so hard about the code. Really. Some of these "consultants" had teams of 20+ people here. I think that they must never have seen UNIX before in a production environment.

    This industry is very, very full of the clueless, and not all of them are running NT (most, yes, but not all). When people keep talking about the coming IT salary shakeout, I think of situations like this, and lots of others, just from the last few years. Good people will always be in demand. The lusers will rapidly find it hard to pay their bills. And this is not new -- it is just filtering from the most structured areas (that would have been MVS/COBOL shops) to the least structured (just wait, web-designer weenies -- your time will come), and it is hitting UNIX now. I think that the excuse of "this is just wild and crazy code and I no mortal man could wade through this spagetti" will soon hold as much water as "it's the compiler -- it hates me!" Heh. With this company, they were not clueless -- they kept the 3090 and never ever seriously considered NT. But UNIX was still believed to be bad juju and scary, so they accepted the explanations. I suspect that they won't in the future, as we are not missing chance to point out how clear things really are.

    And, as an aside, not a single one of the COBOL guys that I knew (actually, a lot of them were and are women) were never out of work more than a few weeks, and some of them have been keying for dollars since before I was born (1970, folks). Their only recent job changes have been to jobs paying $200+ an hour.

    Personally, I cannot fscking wait until some of these Thai-stick Bogarting full-of-BS tool-dependant Shockwave-inflicting pretentious "artist" wannabes that make web front ends to business site such a holy terror to implement for those of us with actual skills (like perl and DB2) start being forced on pain of no work and subsequent drug withdrawl to fscking write fscking proper fscking HT-fscking-ML to the fscking spec the client fscking asked for. Without the little moving GIFs. Grrrrrr ...
  • Of course not. We all know that M$ already knows all about writing bad code.
  • Having spent most of this year climbing through other's crappily written legacy HTML, it was such a nice change to have to write my OWN code from scratch starting in October.
    I was handing off pages to our PERL and PHP programmers, and they knew *exactly* where everything they had to do went, and why.
    I only commented a few sections, but by gum they were the important ones.
    Now I'm reusing 70% of the code to do 3 sections in one month, whereas the last section took a whole month to do.
    If this continues, I'll work myself into a looong paid vacation :). As it is, I only "work" 5 hours out of the 8 I get paid for. After the last month, I "deserve" a break.
    It'll be back to normal come December when the new stuff comes in, but right now, I'm enjoying the fruits of my labour.
    Work smarter, not harder, neh? :)

  • To make your code understandable only to you, you do not need dozens of methods -- you need only 1. Apply password selection procedures to function names. Remember, a password is your dog's name, but with numbers in it (like your vet's phone number modulo its greatest common factor with 3) and written in h4x0r-speak.
  • I have a cow-orker (we're both programmers) who once spent a day lauding the benefits of word wrap in editors, despite denials from the rest of us. Now I indent all of my code so that the lines just "happen" to wrap in such a way that it seems to nest wrong only for him. >:)
  • My mistake, posted too hastily it should have read more like.

    int i=0, x =5;

    for(i=x; i-->0;) { //do stuff }

    Bad Command Or File Name
  • I stumbled across this unmaintainable code article a long time ago (early this year, I think) while looking through the Java glossery, hosted at the same site. Why is it just being reported now?
  • by Crouchy ( 7129 ) on Thursday November 18, 1999 @07:15PM (#1520542)
    Rule of thumb here.. Write two sets of code, one with utter drivel, the other well maintained.
    One you don't shoot yourself in the foot..
    Two you have job security...

  • Hey, I resent them mentioning these beauties! I love using nested ternaries. Strange no body else does, but I actually think they are quite usable.

    Then again, I don't get much opportunity to use them these days...damn 4GL gibberish =)
  • The site was slashdotted, so this might be on it. What I like to do:

    Name variables a series of l's (the letter) and 1's (the number). So you'll have:


    and so on. Sure, if they use a font that clearly shows the difference, it's no fun. But it can be!
  • Whole function on one page!? Hell, I have functions whose calls don't even fit on one page.

    Sadly true...
  • by Anonymous Coward on Thursday November 18, 1999 @07:25PM (#1520546)
    as a cs student, nothing inspires me more! job security rules!

    Good evening class. I'll be your exorcizer of idealistic nonsense for the evening. Just call me Bruce.

    Now... preach all you like about how hard it'll be for the next guy, but like customizing my car or my house... I don't worry about what the next guy will think about my code. Do you care if the next owner of your car might not like it if you paint it red? Do you care if the next owner of your house disapproves of you converting the garage into a pool room? Heck no. Well, it's the same with me. I work for my own benefit, pleasure, and satisfaction. And to do that I've gotta do the best damn job I can at work. Otherwise; no money; no fun. This philosophy is reflected in my code as well. I've cranked out some godawful nasty kluges that confuse even me when I look at them a year later... but I got the job done, by the deadline, while some of the junior programmers seem to wanna rewrite everything to make it clean rather than break the nice design of the code. Feh. That's why they're junior programmers. They Just Don't Get It (tm). Their plan would send the company under. Stuff's gotta be done now and ship next week or there's no profit for the company and no salary for the programmers. Junior programmers always seem to be self-delusional with grand plans of redesigning everything. It never happens. Requirements change *ALL* *THE* *TIME*. Any static plan is doomed to fail. Once they realize this they make the transition from dreaming programmer to master hacker... or they can't keep up with the pace of real world business and disappear. You've got to be able to deal with old crusty projects written by long gone staff with more bags and bells and whistles and ornaments hanging off the side and kluged into it, written by more people you've never met, and you've got to be able to quickly and successfully hack more stuff into it and hack it and rehack it and change old stuff and keep it all running. Successful, on the fly, under the gun kluging is what distunguishes the Senior Programmers driving the big smog polluting, shitty mileage, comfy luxury cars into the front, covered parking space and getting the stock options and profit sharing and 401Ks from the idealist larval dreamers driving their small car becuase "it's good for the environment". Self-spirit-lifting-and-self justification-bull. Given the Big Bucks, you'd ditch that Civic for a gas guzzling SUV or Corvette too. So forget the dream. Getting a clean slate to build on is a rare event. 99% of all programming jobs you'll ever be hired for will be holding together someone else's code. Insane deadlines, getting the jump on the competition mid project, reamping of requirements (many times over), decision reversals by management, your latest self-gratifying achievement being abandoned and dumped because it's not needed anymore. These will all eventually break your spirits. On the plus side, once you realize this, you will be able to succeed and advance within your company or find it easy to get hired at the next comapny. because quick thinking master hackers who can do the magic again and again despite laying waste to the original vision and still keep on kluging and have it keep on working are what companies want. If you can do this, you will succeed. Getting back to the original question... do I obfuscate my code? It may certainly look that way to the idealist, but not so. True brilliance is messy. Remember the famous comment preceeding the task switching code in Unix... /* You are not expected to understand this */ But if you can, you'll be a god... or root... what's the difference again? Anyway, class dismissed.

  • You ever had a dog that likes to steal food off your plate? A good way to make him stop is poor some hot sauce all over some food, leave were he can get to it, and leave the room for a while. when you come back, the dog will be quite unhappy.

    if you let someone get burned by their own bad habits, it is sometimes enough to break them of those habits.

    the article is a bit sarcastic.... at least thats how i read it.

  • I feel your pain. I've basically implemented 90% of the "unmaintainable code" rules. Not because I was trying to, but because of the ever expanding "feature creap". My most favorite scenario:


    Me: Well I'm done with that latest addition you asked for. I'm going to clean the code up a bit and then head home.
    PHB: Oh that can wait, can you add -insert feature here- and have it up by the end of the day on monday?

    Its so hard to get mad when they're paying you that much. And in the end, it is job security ;)

  • I'm in charge of a rather large communications system (between a central office, several warehouses, and a few hundred stores). We are now in the process of porting everything, lot stock & barrel, to new hardware and new OS (SCO 5).

    A) The *original* system was done on a UNISYS mainframe. Hence the initial style of this pile of rubbish.

    B) Half the system is in a 4GL language, written by programmers that were learning the language for the first time.

    C) Half the system was written in shell scripts. They were originally plain bourne shell (yuck), and some kind soul decided to convert them all to Korn. Unfortunately, that consisted mainly of changing the #! line. Utterly worthless.

    D) Raw SQL is sprawled all throughout this stuff. The statements for executing each of these SQL scripts varries in ways you can't imagine.

    E) Three-quarters of this code is on 13 different HP-UX boxes. Very old HP boxes.

    F) The rest is on old SCO 3.x/4.x boxes, which were never properly installed to begin with (they core dump every time you try to shutdown the system). There is no way in hell I'm ever trying to re-install them. Never.

    G) The entire system consists of about 500 shell scripts, 70 or so 4GL programs, and several hundred SQL scripts -- many of which are dynamically modified and executed by said shell/4GL programs.

    H) I'm only about the fifth person to be put in charge of this code since it was written. Nobody with any experience in it works here any longer.

    I think I'm going to learn to tie a noose this week =)

  • Except it should be more of a guideline, than a strict rule.

    Shouldn't everything?

    Anyone blindly adhering to a rule like that must have forgotten the meaning.

    The spirit of the rule is to have understandable maintainable code - the function should be small enough to twist your mind around without getting sucked into a mental whirlpool of pointers to pointers to..., and besides you don't wnat to have to scroll too much :)

    Obeying the letter of style rules is counter-productive - it shows a lack of understanding of the spirit.
  • With all the talk of job security (I realize most people are saying it with tongue-in-cheek), you'd think we were auto-assembly-line workers. If job security really is an issue for you, you must be a damn poor programmer to start with.
    Now, having said that, the link in question was undoubtable funny, and I'm sure none among us can cast the first stone when it comes to the listed offenses, though I doubt most really do it for job security. Usually, its the insane deadline pressure or the dreaded feature creep.
  • Why write two sets of code just for the sake of job security? Makes you half as productive and ever tried understanding bad code from the good equivalent? It's just seems pointless to me. Just do youself a favor a write good code to begin with and stick to it.
    --------------------------------------------- --
  • Welcome to hell ;-) I work in a similar situation where I'm required to debug and maintain "applications" that use shell scripts (bourne) like they were free money. It's always invigorating to follow a shell script that chains through five other scripts, via rshell, to three other systems before completing its miracle mile back where it started. Makes it really interesting, especially since a lot of information is hard coded in (like hostnames), and if one script bombs, you never know which one it is. Another nifty trick I've seen here is to cut and paste your way to glory by copying the same cryptic routine over and over again with small variations on a theme.

    And finally, don't forget to make it IMPOSSIBLE to call the scripts by hand, something in the style of:
  • How many of the suggestions have you done:
    None of them; all of my code is squeaky-clean
    All of them, and proud of it.
    3 + 6i of them
    Hey, what about 16-19?
  • Well I'm still a staunch opponent of using goto. Maybe goto makes you feel superior because you're using Microsoft's crown jewel of BASIC programming but unless you've got employers to impress Microsoft isn't everything.
  • by phantomlord ( 38815 ) <<moc.hcetwrk> <ta> <todhsals>> on Thursday November 18, 1999 @09:12PM (#1520581) Journal
    Remember the old motto...

    If you can't be replaced, you can't be promoted.
  • by Anonymous Coward
    ... if you think anyone would EVER be a victim of this practice. You think they want to rewrite the whole thing from scratch just to have the joy of firing you. I had a prof who told us his strategy when he worked as a programmer - leave the company so that they have hire you as a consultant at four times what you were making because you are the only one who can figure out your code. Brilliant! I used to write maintainable code. My boss once told me how great my coding and commenting was because anyone who came along later could figure it out. Then he retired. The next recession things slowed down, and I got cut because any newbie could read my code and build on it, while everyone else stayed around because they were invaluable - their coding was complex. I would tell people in interviews about my boss's comments on my code maintainability, AND THEY DIDN'T CARE. It's a moot point with employers, they don't have the vision to look ahead and value maintainable code, and they will throw you on the street the first chance they get if it doesn't hurt them. So I say screw them and make yourself invaluable.
  • It is apparent that your company is using a very ad hoc development process. It is UP TO YOU to work to change this, particularly if you're working with a lot of non-technical people. Try and convince your management to implement a formal development process. For each project, write a requirements document. Make several parties sign off on it. Make it so that any change to the requirements also has to be signed off by all parties. Whenever they requiest a new feature, simply tell them: "Adding feature x will take another 10 days. Either we can push the schedule back by 10 days, or we can remove feature y or feature z." This gives them a few choices, and if they insist that you implement both features, tell them it's impossible, and that they should know that as you've already set out the schedule and had them sign off on it.

    As a responsible, professional software engineer, these are things you should be trying to do. If there is resistence to implementing a formal development process, you may have to negotiate a little bit. But ultimately, there is nothing unreasonable about doing business in a formal, well-defined manner. If they refuse to do things this way, make sure you remind them that there will be serious consequences (personally I would threaten to quit the job and work for a more reasonable employer, but that's not for everyone): bad software, missed deadlines, and maintenance hell. This gets you completely off the hook if anything goes wrong. And when things do go wrong, they'll think "he was right", and they'll realize just how good you really are.

    If you want to be a successful software engineer, you need to adopt the attitude that you will NEVER be involved in a failed project (I had the chance to take an excellent course with Marshall Cline, of C++ FAQ fame, and this is one of the things he stressed most heavily and I see a lot of truth in it). You need to take a proactive approach. Take steps to ensure that management is doing things right, rather than simply sitting back and carrying out their instructions without saying a word. Of course, be diplomatic. This is part of a software engineer's job, IMHO. It is things like this that separate the men from the boys in the industry; the true software engineers from the coding monkeys. If you are a software engineer, it's your job to ensure that the company develops the best software possible, or at a more fundamental level, to minimize the time, money, and risk the company expends on the project. Doing that involves more than just coding.
  • I don't know that it's necessarily possible to get a "universal language", but an algorithms repository with a set of translators to other languages would be cool, to the extent it can be made to work.

    That being said, there is at least one project to create a language and editor that use "structured data" like he describes, which I founded, see "". I'm not going to claim it will be a universal language though!
  • by Anonymous Coward
    The great artists know every rule they are breaking and can explain what they hoped to accomplish by breaking a rule.
  • Geez, it's funny! Laugh! To everyone who wrote, "Well, these are serious reasons why you /should/ write maintainable code," YES! OF COURSE! Of course you should do your best to make your code reusable, modifyable, easy to understand, efficient, etc. but this article was about doing the exact opposite! because IT'S A JOKE!

    Sheesh. :)

  • The most interesting line of comments that has popped up is the one associating unmaintainable code with specific languages. Notice though that the article specifically mentions Java, which is among the clearest languages today (though not without its faults).

    What differentiates maintainable code from spaghetti code is not just whether or not the syntax of the language allows for obfuscated code, or if all of the variables and functions are documented and clearly named, if some code conventions are followed or if it has been run through a beautifier, but whether the code was written with a clearly thought-out and documented design.

    If the programmer has actually taken the time to think about the data structures, the algorithms, and the classes(or program sections if you aren't using an OO language), then the code becomes truly understandable. This is not to say that you can then ignore good programming techniques -- they are still necessary -- but that documenting every function, variable and data structure in a program that is otherwise a crufty mess is pretty much a waste of effort. Try it sometime -- look at the source code for Perl, and have the perlguts man page and Gisle Aas's wonderful illustrated guide to Perl's internals [] handy, and you'll get the idea.

    I've seen code in lots of languages that would be considered 'maintainable' if all it took was strictly following a convention, but in fact was frustratingly difficult to maintain because the programmer didn't have a clear design for the system.

  • Some of my favorites, all of them true stories about code I had to maintain:
    • If your program executes one of many different unrelated functions on each run, don't use any of them steenkin' Commie pinko data structures like a dispatcher table, and for Pete's sake don't split the various functions into different source files. Put it all into one enormous if ... else if ... else if ... statement that extends across 10,000 lines. Hey, if they want to change a line of your code, they better be sure that the whole thing still compiles.
    • If you must break up functionality into subroutines, use global variables with reckless abandon!
    • Whitespace slows down your compiler or your interpreter! So cram that code into as few characters as possible! (I had a colleague who really believed this.)
    • Are you worried that upgrades to system libraries will break existing programs? No problem, just install them on some non-standard path, like in your home directory, and link them in from there. You don't need to tell your colleagues where to find them, because surely you'll get around to re-installing them in the right place Real Soon Now.
      Say you're programming CGIs in Perl using modules. Whatever you do, don't install new modules in the system-wide site library, because that could cause all kinds of trouble! Better to put them all in /cgi-bin/lib/ and use use lib '../lib'; to bind them in. But what if you have test scripts in /cgi-bin/test/? No problem, just install the same modules all over again into /cgi-bin/test/lib/ (don't be too picky about whether you're using the same module versions). And if you have mod_perl registry scripts under /perl/, then install all those suckers under /perl/lib/ and under /perl/lib/test/ all over again! So what if you end up with four different versions of the same modules, at least you didn't take any chances the system-wide installation.
  • I have done this in the past and I had a good reason for it:

    I was working in a PC Support role at the time and there was no mention of programming in my contract. I was, however, asked to write and maintain some programs written in Visual Basic for Excel. No agreement was made to provide them with the source code to the program, but it isn't possible to not provide them with the source code and VB for Excel is Interpreted at runtime and not compiled. Hence they would receive the code no matter what. I wrote well structured code where all variables were clearly defined and well named, but before unleashing the code to production I made a copy on a floppy and removed all comments from the production version. I also used global search and replace to rename all variables to a,b,c,d,e etc... The reason I did this was I kind of resented the fact that I was doing something that I wasn't been paid anything near what I should be getting for doing it. On a flip side, they never recognised my coding skills and I left the company a few years ago for better pastures. I still have the floppy and the programs are still in use, I will gladly do contract work for them to make changes. At a contract rate, of course.

    This also has an analogy to contractors leaving time-bombs in systems to protect themselves. The practice is un-ethical, but hey - take a closer look at corporate life, what makes you think that's ethical? If you are dis-gruntled about doing coding when you are not being paid for it them it becomes very easy to justify this kind of practice. If you are being paid to do coding, then your contract should include an agreement to document your code according to a set of guidelines. Woe betide any foolish coder who uses the practices above while bound to such a contract.
  • Interleave your code with as much trace code and printfs as possible. This way even the expert maintainer really can't figure out what statement does something useful.
  • "Don't be irreplacable. If you can't be replaced, you can't be promoted."

    This works. Trust me.
  • Don't forget that you should always hire Fortran programmers to maintain your C++ code, Aural Basic programmers to maintain your Perl code, and Cobol programmers to maintain your Java code.

    Why? Because that's what everyone's doing, at which point they bitch and moan about how their Fortran, Basic, and Cobol programmers can't understand the C++, Perl, and Java code you've written.

    Funny thing.

    They sometimes even have the unbridled audacity and incredible stupidity to demand that you convert your code to look like the languages that the "maintenance programmers" understand. I've never come up with a better answer than to suggest that people run very far, very fast from this all to prevalent mentality. The world is a strange place.

  • Actually, you can define variables at the start of any scope, for example:

    if (foo)


    int i = 0;


    and in C++ you can define them in the for itself:

    for (int i = 0; i &lt 100; ++i)

  • Maybe they were deliberately goldbricking to extract more hourly pay from your employer! This is yet another danger of ignorance and prejudice. If your only conception of Unix is that it's "bad juju", it's easy for unscrupulous people to take advantage of you.

    Vovida, OS VoIP
    Beer recipe: free! #Source
    Cold pints: $2 #Product

  • Rewrite with extreme prejudice.

    Vovida, OS VoIP
    Beer recipe: free! #Source
    Cold pints: $2 #Product

  • Most obviously obfuscated code is produced by relative newbies who don't know what all the features of a language are for (e.g. case conditionals implemented as loops etc.) It never looks professional to code this way.

    And, after you've seen a few thousand modules done this way, you can pretty much burn through them; it's actually kind of fun, like doing a puzzle.

    The evil done by obfuscated code is nothing compared to the evil done by obfuscated architectures. Any power you give somebody can be used for good or evil, and the power you have when designing in architectural dimensions (like class hierarchies or APIs) is both greater and more subtle. Example: DDE. Real world projects include not only bits of code, but class hierarchies, databases, file formats, external interfaces etc. You can write code as limpidly as Kernighan and Ritchie, but still end up with a system that is totally unmaintainable by anybody but you. Furthermore, it will be utterly unclear to anyone whether this was deliberate, or caused by technical constraints (i.e. things you must interface with), or is somehow tied up in the nature of the problem.

    Write overly complicated code, and people will think you're an idiot. Design overly complicated systems and write beautiful code to solve the unnecessary problems you create, and they'll think you're a genius.

  • >But you're still in the wrong here. Instead why didn't you create the
    >best, most maintainable code possible and then show them. Prove you're
    >worth the extra bucks and you'll get it. On the other hand, prove that
    >you're a bitter script-kiddie and you'll get paid accordingly.

    First, I'm not saying what he did was right.

    But, the truth is that business types will walk all over you if you let them. I got out of college, and started into the industry. I went to work for a company for a VERY low salary. I figured I would show them how good a coder I was, and they would up my salary. According to the other people who worked there, and saw/used/maintained my code, I am a pretty good coder. I was there for nine months and (finally) got a SIX PERCENT raise. The average salary where I am was almost twice what I was making.

    The business types don't really care how good you are, or how much you code, or how good your code is, they care how much you yell and scream your head off.

    >>>>>>>>>> Kvort
  • Well I'm scared because I don't know if that is sarcasm or not. I guess I'm an idealist. I like to /design/ systems. Coding is just what you have to do to make your design concrete. A lot of people don't think this way. They think the code is the end, not the means. And hence you get nasty messy complex weak broken sorry ass systems and you need more people to support them than if you actually designed it correctly the first time. Sometimes I have to work on a project and I have to hold myself back from slapping everybody and starting from the ground up...I just have to grit my teeth and get my hands dirty so I can fix the a symptom of a much larger problem. Computing is truly going to hell if the above was /not/ satire...
  • My previous employer had a HUGE Dos system.

    Started in BASIC, went through an interpereter to C and still had bits of assembler for certian bits. Wow, this code SUCKED.

    I didn't have much to do with it, but I did have to emulate some things it was doing in a new Windows system (ewww).

    The best part was when I found out that 'S' was a global void *. Depending on the part of the program it was used for a half a dozen different types. The structured programmer in me had spazmotic fits, but I couldn't have the programmer killed cause he was the owner of the company.

    Oh, there was also a global 's' which was declared as an int but used as a void *.

    Oh well, back to my stupid Access project. How can anyone work in a language without pointers? :-)
    -- I'm omnipotent, I just don't care.
  • My first job experience was to help port some old Fortran code, from a mainframe to a workstation, and from Fortran-77 to Fortran-90. There were revisions and comments dating back to 1983 (this was in 96-97)... (Aside: There's an age/revision level past which code should NOT be maintained, it should be rewritten)

    All in all it was a great learning experience. I've developed an aversion to spaghetti since then.

    Imagine if you will, a 2000+ line subroutine containing many a multi-level if-else/for-do construct, from the depths of which conditional computed GOTO statements jumped into the middle of another multi-level for-do/if-else loop. Intercal [] was never more fun.

    The true kick of the experience was that it was to be a code port. Not a rewrite. Not even a little. A straight port, so the original developers wouldn't have to figure out any new logic. Feh!
  • by hawk ( 1151 )
    >They asked him to do something that he was not
    >contractually obligated to do, that he was
    >not being paid to do, and he did it anyways...
    >and he's a thief?

    No, he wasn't contractually obligated--at the time he was asked. Once he began the work, it modified the contract (more technically: the company offered a contract modification, and he accepted it by performance).

    Once he undertook the duty, he was obligated to due so correctly.

    The company did *not* try to get something for nothing. They requested a service at the rate he was already receiving. He took the money to do so. And stole the work that he was paid to perform.

    [overrated? at a default? hmm . . .]
  • I think you've missed the whole point of Hungarian notation. Those examples you used were quite contrived (and if they did actually exist in code, it is the coder's errror, not the convention).

    HN is a good way to indicate the kind of variable, and it does not preclude meaningfull name. What is maxTypeCode? A string? An int pointer? Pointer to a user defined type? I don't know without scrolling back up to the declaration. is numLinePayments a signed or unsigned int? On the other hand, pszMaxTypeCode tells me instantly that it's a string and iNumLinePayments is signed.

    Likewise, your iNmPt example illustrates braindead programmers, not the shortcomings of HN. It should have been called iNumLinePayments.

    I think too many unix coders are frightened off from HN simply because it came from Microsoft. Don't be. Try out HN, and if you don't like it properly used, then don't use it.
  • > What is maxTypeCode? A string? An int pointer? Pointer to a user defined type?

    Unless you're writing a device driver, WHO CARES? If you stick to the functional interface used for creating, setting, and passing that value, the type of maxTypeCode is OPAQUE. It's called ABSTRACTION, something we learn when we stop having to know encode our routines for sizeof().

  • by scrytch ( 9198 ) <> on Friday November 19, 1999 @11:21AM (#1520750)
    Is that you get chained to your code. The volume of documentation on my code is bigger than my code, because I can hand it to someone, say "this is all you need to know", and leave that code behind. Forever. On to bigger and better projects.
  • I don't know whether to hug you or hunt you down, tackle your sorry ass to the ground, gnaw through your rib cage and tear your still beating heart out with my bare teeth.

    I uh ... I'm not sure I'd want you to hug me either, now...
  • by hawk ( 1151 )
    >Even if he did implicitly agree to a contract

    Actually, it's explicit: the modified contract is accepted by performing the action

    >(he may have; IANL,

    but I am :)

    >and the law has stranger things in it...)

    nothing strange here; this is no different as a legal principal than working eight hours instead of the six in your contract, and expecting an extra two hours pay.

    >- did he also implicitly enter into an assumed
    >modification that assigned intellectual property
    >of his creation to the company?

    It was work for hire. The employer is entitled to all of it.

    >If not, and there was no such assignment in his
    >original contract, then he owned the code, and >was free to do with it as he wished.

    If for some reason there wasn't, he was stealing when he did it during time the company was paying him . . .

    >Once he undertook the duty, he was obligated to
    >due so correctly.

    >Legally, or morally?


    >Morally, I'd agree with
    >you... if he made the commitment, I think he
    >should have followed through. Legally, though, I
    >don't think there was a commitment, and
    >he can't be held accountable for not doing work >he was never hired to do.

    He was doing it on company time, for which he was paid. He then vandalized, it, and took the copy he wasn't entitled to.

  • I understand what you're saying. However, those examples are not contrived. Those are pretty close to real variables from real code I had to work with. Actually, they were part of the 2100+ line function that I referred to in my first point. By the way, I replaced the 2100 line function, with its obfuscated naming conventions, which wasn't completed and didn't work at all, with 12 functions over 718 lines of code---over 20% comments---that the project manager, a non-coder, looked at and said "Hey! I can understand this! And it should work!" And it did. :)

    In any case, your point is well taken, that Hungarian notation is not as obfuscated as my not-so-contrived example makes out. My only experience with it however was on this one project which did have such convoluted examples. Hopefully my example speaks to the broader issue of useful variable naming, not just Hungarian notation.

  • It makes all the difference in the world if you're a code *maintainer*, as this whole article is about. If you write code only for yourself, then you can use any coding standard you want. But then again, if you're only coding for yourself, why even release it :-)

    A maintainer DOES NOT want to flip up to the top of the header files each and every time he runs across a variable to find out what it is. If a bug is signed versus unsigned related, "maxTypeCode" doesn't help at all. But an "uMaxTypeCode = -3" sticks out like a sore thumb.
  • Answers are: integer, pointer (to something), char, float, and who cares :-)

    Without looking anything up, I think mps is a Microsoft/Windows/vc++ specific prefix. I do recall that "h" was for handle, and when you're using handles for *everything* in windows programming, it makes it much easier to distinguish between ints, files and handles.

    But just like the guy who avoided all whitespace because he was following the rule to keep all functions one page in length, you can overdo HN. The basic idea is to use easy to remember mnemonics with prefix notation. Using "intEmployee" and "dblSalary" is equally useful.
  • by GC ( 19160 )
    Thanks for the discussion. I have to add that I was asked to produce something which would perform the tasks required. This involved coding, but the manager who actually set me the task did not know enought to know that it was an actual program that was required. They have a working system and that was what I was asked to produce. I don't believe I am a thief and all parties involved are happy with what they have got out of it. Perhaps: A victimless crime?

    Shall I go to a police station and confess?

    Also note I was employed in the UK and you cannot apply US employment law to my case.

    Some of the comments in this thread are actually quite surprising to me. There is the air that every employee should always bow their heads to their managers and never do things for themselves. There also seems to be the opinion that everyone should be selfless and not look out for number one.

    I confess, I don't believe in this ethos. At the end of the day all I care about is myself and those that care about me, the rest are immaterial, but they needn't go to hell.

    I did do other coding in this employment and did not alter the code, leaving explanatory comments and even writing a 40 page manual of how the system worked and both user and programmer references. In all the time I was employed there my salary rose by only 3% (OVER TWO YEARS). PC Support Analyst to Developer?

    And it seems I still am judged by my peers as a thief, the devil incarnate perhaps?

    Oh well, lets leave this one to the archives of /.
  • >Oh well, lets leave this one to the archives of

    Good idea, it's beaten to death. But one little note: I'm not talking about US employment law, but the Common Law of England :) For the most part, that is still the law in the U.S., but were old law by the time we separated.

    hawk, esq.

"The voters have spoken, the bastards..." -- unknown