Home > technical > Conscious Degradation Of Style

Conscious Degradation Of Style

One (of many) of my pet peeves can be called “Conscious Degradation Of Style” (CDOS). CDOS is what happens when a programmer purposely disregards the style in an existing code base while making changes/additions to it. It’s even more annoying when the style mismatch is pointed out to the perpetrator and he/she continues to pee all over the code to mark his/her territory. Sheesh.

When I have to make “local” changes to an existing code base, if I can discern some kind of consistent style within the code (which may be a challenge in itself!), I consciously and mightily try to preserve that style when I make the changes – no matter how much my ego may “disagree” with the naming, formatting, idiomatic, and implementation patterns in the code. That freakin’ makes (dollars and) sense, no?

What about you, what do you do?

  1. javafish
    • December 19, 2011 at 4:20 am

      Nice find. I’m surprised that the Java code was found to have the highest technical debt of the languages they tested.

      You missed your calling. Never too late to become a software developer.

  2. javafish
    December 19, 2011 at 8:43 am

    I don’t think it’s the fault of Java. Java was written so that any dumass with a keyboard could ‘code’ a process and make something happen. Since it’s mostly a pre-defined set of tool/functions that you just have to plug together into an action chain of sorts, you can force process activity to bluntly stumble through what you want to do. Elegance, ‘style’, and grace have been set aside in favor of just getting it done. The other programming languages in that list have much higher order constructions because they require more specialized ability and programming knowledge to execute. When something is more difficult to do, people take more time to do it, and since the time-investment is so high, they also take more care of HOW they do it. Look at the illustrated bibles of the Middle Ages.

    Same kind of thing happens in my business. It used to be that to present an idea to a customer, designers had to be artists–we spent hours (and even days sometimes) to create a nice pretty picture using pencils, water colors, markers, and ink, to effectively (and artistically) illustrate a structural concept sufficiently and eloquently enough to convince a customer to outlay large amounts of cash to actually build the idea to promote their product. Everyone with the skill-set to perform at this level had their own ‘style’ and flair, and when up against the competition on a project, these art-shows could get pretty tough, depending on who the illustrator on the other side of the room happened to be. Another artist could never pick up your half-finished drawing and complete it. It just wouldn’t work.

    Nowadays, any 3-fingered clunk with a keyboard and a mouse can ‘create’ a 3D view of an idea, click on a few pre-defined textures and backgrounds, select a light-source, plop in a camera, and ‘render’ their idea, presentably enough that someone else with no visual acumen can glance at it and decide if they want to buy it or not. If 10 hairless apes all do the same thing with similar textures and light sources, they all can generate similar-looking images with enough realism to eliminate any sense of the ‘hand’ that created each image–they become interchangeable.

    We’ve moved from the lone genius in a dark room by themselves, to the Henry Ford model of mass-production. Each gorilla at a seat plugs in one part of the equation, for increased efficiency and higher output. Lower costs, but no style. Look at a car like a Bugatti or Dusenburg, compared stylistically to a Camry. Both have wheels and an engine, and both can get you from one place to another, but which one would you rather drive for the Fourth of July Parade?

    The biggest difference though with Code, is that only you and a few other back-room magicians ever get the opportunity to look under the hood and see the structure of order in the creation. And given the plug-n-play basis of everything we do these days, not that many care about maintaining that order, because they all have their own, better way. And besides, they’ve got to get back to Call of Duty to blow away some more bad guys.

    • December 19, 2011 at 8:56 am

      Nice essay. How’d you know that I am a three fingered, clunky, hairless ape?

      On a different note, since you’re my favorite commenter, I’ve got an invitation for you. Wanna try your hand at writing a guest post for BD00? If interested, e-mail me.

  3. December 19, 2011 at 10:37 am

    I agree that when making small changes to existing code you should, as best as possible, use the style already present in the code.

    I do make one exception though. Sometimes the existing style may be antiquated (with respect to your current coding guidelines), or the style may be prone to particular types of defects. In these cases I find improving the touched sections of code is acceptable.

    • December 19, 2011 at 11:00 am

      Yeah, it’s really never a cut and dried decision.

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: