I recently came across a bit of code with a comment that stated that this hack was being made quickly for the launch of a site but that it was important to figure out a permanent solution. The comment was from 2008 and I came across it because I was porting the logic to a global area of our site. The hack was still necessary, so I left it in. I'd planned to at least update the comment with something snarky, but I scrolled down further and found another temporary piece of code from 2007. I'd wrapped some QA code and deployed it to live so that a vendor could test some work they were doing for us. I actually removed this hack, but I pasted the former hack into the new global area with the comment unchanged.
I started noticing problems everywhere in our page code. There are <div>s wrapping other <div>s to add new styles when it'd be more appropriate to add another class name to an existing <div>, fix the bug in the current styles, or write a new selector. Our styles often have selectors with one class name and are peppered with !importants to override selectors targeting a parent node (a good time to use the 'cascading' in cascading style sheets). Our scripts gradually acquire more global variables to maintain an ever more delicate application state. Some variable names suggest that they do the same thing but they were added by different people and so they do slightly different things. Older files have larger and larger blocks of commented code and we have many files, under version control, with copies of older files in the same directly suffixed with .bak, _OLD or even a person's name.
I call this Additive Coding.
I've been guilty of this because:
I once had a coworker ask me for an explanation about why I wrote a couple of lines. Just two lines above where they were looking, I had written a comment explaining, which they hadn't read because they'd trained themselves to 'ignore comments because it's usually commented code'. We need to delete and refactor.
When you're working through the first iteration of your own code, especially, it's important to keep it clean and easily understood. You'll be able to rewrite it and the next draft will be better.
If you have to keep going back to the API, you'll learn the API. You may find documentation by the author that will suggest a better way or tell you that the function was deprecated two minor versions ago and not to rely on it any longer.
Version control ought to be enough to avoid commenting large blocks of old code and creating backup files.
Even though it might be quicker now to just add another <div>, an !important or to check for a specific condition in rickety code, it's painful in the long run. It results in a chaotic situation in which everyone is fine with their own code but disgusted with the amalgam.
I recently came across a bit of code with a comment that stated that this hack was being made quickly for the launch of a site but that it was important to figure out a permanent solution. The comment was from 2008 and I came across it because I was porting the logic to a global area of our site. The hack was still necessary, so I left it in. I'd planned to at least update the comment with something snarky, but I scrolled down further and found another temporary piece of code from 2007. I'd wrapped some QA code and deployed it to live so that a vendor could test some work they were doing for us. I actually removed this hack, but I pasted the former hack into the new global area with the comment unchanged.
I started noticing problems everywhere in our page code. There are <div>s wrapping other <div>s to add new styles when it'd be more appropriate to add another class name to an existing <div>, fix the bug in the current styles, or write a new selector. Our styles often have selectors with one class name and are peppered with !importants to override selectors targeting a parent node (a good time to use the 'cascading' in cascading style sheets). Our scripts gradually acquire more global variables to maintain an ever more delicate application state. Some variable names suggest that they do the same thing but they were added by different people and so they do slightly different things. Older files have larger and larger blocks of commented code and we have many files, under version control, with copies of older files in the same directly suffixed with .bak, _OLD or even a person's name.
I call this Additive Coding.
I've been guilty of this because:
I once had a coworker ask me for an explanation about why I wrote a couple of lines. Just two lines above where they were looking, I had written a comment explaining, which they hadn't read because they'd trained themselves to 'ignore comments because it's usually commented code'. We need to delete and refactor.
When you're working through the first iteration of your own code, especially, it's important to keep it clean and easily understood. You'll be able to rewrite it and the next draft will be better.
If you have to keep going back to the API, you'll learn the API. You may find documentation by the author that will suggest a better way or tell you that the function was deprecated two minor versions ago and not to rely on it any longer.
Version control ought to be enough to avoid commenting large blocks of old code and creating backup files.
Even though it might be quicker now to just add another <div>, an !important or to check for a specific condition in rickety code, it's painful in the long run. It results in a chaotic situation in which everyone is fine with their own code but disgusted with the amalgam.