Lessons Remembered from Bad Code
You know it when you see it: bad code. It's not necessarily code that doesn't work (but it often is). Bad code is hard to parse, has needless complexity, and doesn't take advantage of the language's constructs for making your code easy to follow, edit, augment, and fix. We all have probably been guilty of producing bad code, either through ignorance or laziness. However, it's always something that should be avoided, if possible.
Relating mostly to web development, here is a short list I've compiled off the top of my head:
- using old layout design patterns (e.g. <frame>)
- using <table> instead of <div>
- not using master page/view layouts
- in-line Javascript or CSS
- mixing tons of client-side code with server-side code in the same file
- not using external code files for functions
- redefining the same functions in multiple files
- hard-coding presentation markup in compiled classes
- creating all-new pages for a short amount of information
- label nomenclature inconsistency (i.e. calling it a "bar" here, but a "foo" there)
- using deprecated elements or attributes
- rendering basic functions broken if something the user can disable is turned off (i.e. Javascript)
Nothing here is revolutionary or unique and can be seen from the simplest script to the most complex enterprise application. Still, STOP IT OK GUYS.