Programming practices that piss me off
Sep. 10th, 2007 04:22 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
gizaToday's programming practice (and by "practice", I mean "anti-pattern") that pisses me off is repetition of code.
Generally speaking, having the same piece of code repeated over and over in different parts of the same system is bad, for the following reasons:
1) It makes the overall size of the system bigger. If you have a section of code that is 10 lines long, that's 9 lines longer than a single function call would be. If you have this code repeated 10 times in the system, now you're looking at 90 extra lines of code...
2) It makes fixing bugs or adding features more difficult. Instead of modifying a single function and testing it out, you now have to modify every single instance of this code, which makes for lots of repeitive (and therefore, error-prone) labor, and a larger deployment.
3) It breaks abstraction. It has been my experience that well-designed systems are full of abstractions, which in turn make the system easier to understand and maintain. For example, if I am building a page that displays an item for sale, a well designed project will have code that looks like this:
get_page_header();
get_user_info();
display_product($product_id);
get_page_footer();
While each function should still be documented, well-named functions can make it very obvious what is happening in other parts of the system that call those functions. The above example is certainly much easier to read than say, 100 lines of code that does the same thing.
4) It makes it harder to test. Having code sitting off in its own little function is easier to test, because (in the absense of globals), it is very clear what data is being passed in and what data is returned, if any. When that code is instead inlined into the middle of a page, it becomes much harder to test because now you have to worry about what comes before that section of code -- there is no easy way to isolate it. And unit tests are right out.
For further reading:
- Design pattern
- Functional design
- Anti-pattern
Generally speaking, having the same piece of code repeated over and over in different parts of the same system is bad, for the following reasons:
1) It makes the overall size of the system bigger. If you have a section of code that is 10 lines long, that's 9 lines longer than a single function call would be. If you have this code repeated 10 times in the system, now you're looking at 90 extra lines of code...
2) It makes fixing bugs or adding features more difficult. Instead of modifying a single function and testing it out, you now have to modify every single instance of this code, which makes for lots of repeitive (and therefore, error-prone) labor, and a larger deployment.
3) It breaks abstraction. It has been my experience that well-designed systems are full of abstractions, which in turn make the system easier to understand and maintain. For example, if I am building a page that displays an item for sale, a well designed project will have code that looks like this:
get_page_header();
get_user_info();
display_product($product_id);
get_page_footer();
While each function should still be documented, well-named functions can make it very obvious what is happening in other parts of the system that call those functions. The above example is certainly much easier to read than say, 100 lines of code that does the same thing.
4) It makes it harder to test. Having code sitting off in its own little function is easier to test, because (in the absense of globals), it is very clear what data is being passed in and what data is returned, if any. When that code is instead inlined into the middle of a page, it becomes much harder to test because now you have to worry about what comes before that section of code -- there is no easy way to isolate it. And unit tests are right out.
For further reading:
- Design pattern
- Functional design
- Anti-pattern
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
(no subject)
Date: 2007-09-10 08:56 pm (UTC)The app I'm working on is in PHP, FWIW.
(no subject)
Date: 2007-09-10 09:12 pm (UTC)Um. 80, actually. 10 lines for the function declaration, plus 10 for the 10 function calls.
Probably less than that even, since function declaration is going to involve some overhead of definition of parameters and local temp variables. Maybe some other translation and overhead as well.
Not disagreeing with your argument, just correcting the math.
(Speaking as someone who had to implement this sort of hideous design, due to lack of planning for a common library to put the functions in.)
Alex
(no subject)
Date: 2007-09-10 09:14 pm (UTC)I was thinking in abstractions. ;-)
(no subject)
Date: 2007-09-11 01:34 am (UTC)(no subject)
Date: 2007-09-11 07:19 pm (UTC)It's the worst incarnation of "If it works don't touch it" rule. :(