Look! Responsive Web Design from 1999!
How to Write Unmaintainable Code (1999)
61–70 of 72 posts
Re: How to Write Unmaintainable Code (1999)
#62Earlier quoted context omitted.
Isn't that what TDD is all about? The logical consequence is code that vitally depends on the existence of specific tests.
TDD will leave you with a load of tests which prevent you from changing the code. BDD on the other hand should leave you with a suite that isn't coupled to a specific implementation. Part of the information contained in a test is the intent of the verification being performed, and part is code for mapping that intent onto the implementation. The latter part can be discarded during a rewrite. Cucumber/SpecFlow etc. ma…
> and part is code for mapping that intent onto the implementation
Wait, what?! The more I listen people talking about TDD, the more I discover I always misunderstood it, and the less I want to actually understand it.
Re: How to Write Unmaintainable Code (1999)
#63> E.g. on the screen label the field "Postal Code" but in the code call the associated variable "zip".
If you support multiple countries this is probably an inevitability. Same with province vs state, potentially others.
I guess you could have one variable called "postalCode" and one called "zip", but that seems potentially more confusing.
Also, sometimes your UI shifts - should all your code change then? Because the boss wants to call something different in the UI? "We were calling them admins, now we want to call them CSR." Is it time to write a regexp to rename everything?
Re: How to Write Unmaintainable Code (1999)
#64> E.g. on the screen label the field "Postal Code" but in the code call the associated variable "zip". If you support multiple countries this is probably an inevitability. Same with province vs state, potentially others. I guess you could have one variable called "postalCode" and one called "zip", but that seems potentially more confusing. Also, sometimes your UI shifts - should all your code change then? Because the…
Adding... for web applications use IDs and Classes liberally in the html output... for actual string injection, especially if you support internationalization, this is needed so you can separate the text to display from the controls in place.
Re: How to Write Unmaintainable Code (1999)
#65Earlier quoted context omitted.
One I saw happen: avoid merge conflicts by having each developer maintain their own fork of trunk, or better still, multiple forks. Copy and paste is easier than merge anyway. Automate builds for all these, and provide a way to release any of them, without recording which you used. Never, ever tag. You want to delete branches too? Sure, why not. Of course this makes it hard to track dependencies, so be sure to check…
In Subversion, I've seen branches created, deleted, and then another branch created with the same name from a different subtree of the repository. I was also successfully able to export all of this to git with every deleted branch now still in existence.
I definitely like the git workflow more... branch, work, rebase, PR, review, rework, rebase, review... merge.
short change cycles are easier to reason with.
Re: How to Write Unmaintainable Code (1999)
#66> You earn extra Brownie points whenever the beginning and end of a block appear on separate pages in a printed listing. I'm aware that this is from 1997-1999, but I'm curious: Do people still print out source code for better reading?
I tend to do it whenever I'm working on something I find tricky.
For me it's much easier to focus if I take my printouts and get away from the computer and edit and write code by hand, then go back and type in the changes.
I started doing this when I thought back to times I programmed back in high school and college and remembered that I'd always had the most success with programs working correctly when I'd written them out by hand before typing them in. I think it forces me to really think about what's happening, rather than just trying stuff until things "mostly" work.
I find that when I'm sitting at the computer, I have a much more iterative style, where I try something, see how that went, and make changes. When I'm working out something away from the computer, I have to have a coherent mental model of what I'm trying to accomplish.
So at the computer is good for experimenting and exploration, away from the computer is good for coherent designs.
I think there's something analogous with languages, I find dynamic languages much easier to deal with when I'm sitting at the computer, but if I'm working away from the computer on paper, then I prefer languages like SML or OCaml (or maybe even Go?) where I can look at the code and work through in my head exactly what is going on.
Re: How to Write Unmaintainable Code (1999)
#67There's only one rule: 1. Don't write fast running behavioural tests that verify the software is working as required. With fast running tests I can maintain any old crap. Well, technically speaking I can rewrite it, but no-one will mind.
"Assuming a perfect test suite, ..."
Re: How to Write Unmaintainable Code (1999)
#68I've thought a particularly effective approach is actually to do the "right" thing but take it to ridiculous lengths - the "Enterprise FizzBuzz" that was posted on HN recently being a good example of this.
Use all of the techniques described in the GOF book at the same time.Your flyweight should collapse because the facade was too heavy with decorators to support another observer.
Re: How to Write Unmaintainable Code (1999)
#69"Never put in any { } surrounding your if/else blocks unless they are syntactically obligatory."
Re: How to Write Unmaintainable Code (1999)
#70Writing unmaintainable code increases job security.
You have to get away with it for a while first. Otherwise you get fired before you are the only one that knows what is going on.