• (nodebb) in reply to isthisunique

    Your code might be unmaintainable if your developers use edit, notepad.exe or wordpad as their IDE.

    Actuallly I'd assume such code to be more maintainable than normal standard because, if they do not leave enough hint for in-page navigation (like strict function name policy), coding in such environment will be a pain. (I don't mean if there having strict naming convention then it's not a pain) And with notepad, loading large file is painful so you're unlikely to see code file with > 1MB in size.

    On the other hand if they insist in coding with plain text editors, if you code with normal IDE (notepad is not "integrated"... it doesn't have builtin way to invoke compile command), there is huge chance you can introduce pain to them.

  • (nodebb)

    Your code might be unmaintainable if ..when tasked with a feature to fix or change you start by spending anything up to several hours trawling through a codebase of about eleventy thousand interconnected scripts, looking for any with names that sound as though they might be related to the feature, reading them to work out if they actually are because they have no meaningful description, and grepping the crontab to find out if the script is actually being used.

    ..you've had to appeal to a senior dev after failing a code review because the dev who reviewed it failed to grasp the concept of two conditions not being mutually exclusive, even after you explained it.

    ..you only know that something is bad practice because you saw something like it on TDWTF

    ..it contains comments apologising for it.

    ..the only comment in around 1000 lines (apart from chunks of commented-out code) says simply "in case of fifteen" and nothing about the context lends any comprehension to this.

    ..it contains XUnit tests but standard practice is not to bother adding to them, running them, or updating them so that they still compile before checking in.

    ..95% of the business logic is done in stored procedures, which might encompass several thousand lines each with no meaningful comments. If they're split into multiple procedures which call each other, most of them are cryptically named and none of them have any meaningful description. And they're not in source control.

    Addendum 2016-08-31 10:35:

    [EDIT: forgot one]

    Your code might be unmaintainable if it includes dozens of generated classes (which sometimes need to be regenerated), some of which have been modified in various places without any documentation or any indication at all that this is the case, let alone which files or what the changes are.

  • I dunno LOL ¯\(°_o)/¯ (unregistered)

    A bit late, but it's never too late for a good wtf...

    Your code might be unmaintainable if it's for an embedded device, and of the only three (pre-JTAG) programmer modules that you can find, two are dead and the third is being used on the factory floor by manufacturing. But then you find a newer USB dongle along with a CD-ROM of a newer (but still almost 10 years old) 2.0 version of the compiler that now supports USB dongles, and you can't get the code to compile under the new version because the build system is completely different.

    Your code might be unmaintainable if it uses a C++ framework, and while most of the two hundred or so screens have their own class, the event handling is a single 15000 line method on the base class for all screens, with an enormous switch statement to handle every screen. (aka completely missing the point of C++)

    Your code might be unmaintainable if it was written for a device using a classic 8-bit processor that needs bank switching to handle all the RAM and ROM that it uses. In 2005.

    Your code might be unmaintainable if to change the daylight saving time dates for a potential customer in Mexico (where they never changed from the more sane dates), you have to do it as a binary patch of the 68HC12 code because you still haven't yet figured out how to build and deploy the system properly, as it's from two generations of developers ago, and the previous developer was literally leaving as you were hired. (The change of DST dates is a WTF of it's own. Thanks, Dubya, for being dumb enough to let them talk you into it.)

    Your code might be unmaintainable if the main code repository for it is in CVS on that Windows 2000 machine on top of a file cabinet by the conference room, where people leave donut boxes. And it makes strange grinding noises every now and then. (I sat across the walkway from it. I was at least able to run cvs2svn on the few repos that we were still using. The computer was still there when I left, but I had turned it off since mercifully nobody was using CVS there anymore.)

    The first two were from the display screen part of the project that used a Coldfire CPU and a Green Hills compiler, the next two were 68HC12 and CodeWarrior. (Why not Codewarrior for both?!) And both used two different Motorola-specific debug ports from before JTAG and SWD became the industry standard way to do it. I was unable to do anything useful with the display screen code, there were some serious WTFs that included polling devices to build up select screens (at ~250ms per timeout if there was no device at an address!), but the 68HC12 code was much worse and I don't think I even got as far as installing the compiler because they would call in the previous developer to fix it.

    It was only after I had been there three years or so that the DST issue came up. The code actually checked the year to determine the DST dates to use (the year check was left in even though the device has no reason to care what DST in previous years was), so I binary patched the year it was comparing against to a few centuries ahead.

  • Zenith (unregistered)

    "Your code might be unmaintainable if you have coding standards. Your code might be unmaintainable if you have coding conventions."

    Fixed that for you. I've had many "standards" imposed on me that were anything but. They're always pushed by the least capable developer too. You end up losing 80% of the features of the environment...if you're lucky. To top it all off, after being crapped on for capitalizing an acronym somewhere (dur hur, camel casing), you find the imposer's code riddled with mistakes and are brushed off with "we don't have time to go back and fix it." You can write the fastest, safest, most consistent, most correct code in the world and still be trampled by a virtual cripple with a "standards" document.

    Incidentally, you know my first question in an interview now? "Let me see your code standards." If they won't show me, I walk. I'd follow with "if I don't like them, I walk" but I've never received them. What are they thinking? That a candidate who asks questions like this will just acquiesce to whatever once they've been lured into their trap? Even the places that turned out to be high turnover, did they ever consider such toxic elements of the environment a factor?

  • CSharp (unregistered)

    Your code is unmanageable if and when someone reads your codes for days, throws up their hands and says "WTF!", and the whole project needs to be re-written to make things work.

Leave a comment on “Your Code Might Be Unmaintainable…”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article