I had Susan as a tutor in my first year at Imperial. This made me chuckle.
How to Write Unmaintainable Code (1999)
21–30 of 72 posts
Re: How to Write Unmaintainable Code (1999)
#22> 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?
Just happened, working on a new codebase. I never print more than ~5 pages but it helps me organise the codebase in my head when it's a complex one. As an alternative, I also write down code flows. I always keep a notebook by the laptop.
Re: How to Write Unmaintainable Code (1999)
#23How about obfuscated MUMPS? P R I N T S (A,L)=1,(S,T)=I N G G I V E N A O F A=L:L:S Q:U=A R E S B=E L O W (A*A),! I S (U,R,E)=T H 1 N K I T=S G O O D
Does readable MUMPS even exist?
Re: How to Write Unmaintainable Code (1999)
#24I had Susan as a tutor in my first year at Imperial. This made me chuckle.
Same here ;-)
Re: How to Write Unmaintainable Code (1999)
#25> 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?
> Do people still print out source code for better reading?
Re: How to Write Unmaintainable Code (1999)
#26They are missing the creatieve use of your version control system. First, make sure none of your commits actually build out of the box; forget a file for a few revisions, accidentally check in a corrupted XML file, etc. Create a "trunkV2" directory, and keep committing to both trunk and trunkV2. Add a third trunk inside the "branches" tree (/branches/featureX/newTrunk; I have seen this n practice, with random custome…
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 the binaries of the projects you depend on into your project, especially if those were built on your own machine from source you haven't checked in instead of builds from the build server.
(and when I say 'saw happen', I mean 'I spent a week in Kiev at 12 degrees below freezing trying to figure out where the source code had gone'...we never found all of it)
Re: How to Write Unmaintainable Code (1999)
#27They are missing the creatieve use of your version control system. First, make sure none of your commits actually build out of the box; forget a file for a few revisions, accidentally check in a corrupted XML file, etc. Create a "trunkV2" directory, and keep committing to both trunk and trunkV2. Add a third trunk inside the "branches" tree (/branches/featureX/newTrunk; I have seen this n practice, with random custome…
Also, use git rebase instead of merge.
Re: How to Write Unmaintainable Code (1999)
#28> 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?
The essay was presented half-seriously as part of a module on software maintainability [1], which I took in 2007. Perl was given as an example of a write-only language: modification of a typical Perl program requires at least a partial re-write. (The extra joke was that many of the computing department's internal systems were written in Perl.) More seriously, there were discussions of library versioning schemes, back…
Still, when two writes of a Perl program is less code and time than one write plus one modification of a C program, Perl still looks good.
Re: How to Write Unmaintainable Code (1999)
#29While the advice in the article is funny, on a deeper level the author seems to argue that program text is a rather basic representation that often obstructs insight into the semantics of the program.
The quest for other program representations is still open. The state of the art uses text as "storage" format plus an IDE that does some semantic analysis to help the developer navigate. Many of the ideas mentined in the article (navigation, coloring, auto-format) have been integrated into IDEs and editors.
With almost 20 years of research between the article then and now, what semantic techniques are you dreaming of in your development environment? What are you missing? What feature would greatly improve your productivity (but is possibly too costly to implement by yourself)?
Re: How to Write Unmaintainable Code (1999)
#30They've missed the liberal use of dependency injection, triggers, or anything that can create a side effect of an event without being documented in the function being executed.
Much fun to be had there. Even just setting up PostgreSQL partition tables can defeat the most diligent maintainer (as they suddenly find RETURNING id_column fails everywhere).