How to Write Unmaintainable Code (1999) • Hacker News Board

Re: How to Write Unmaintainable Code (1999)

#51

Post by ihsw » Fri, Sep 18, 2015, 2:15 PM UTC

macca321 wrote: post #35

There'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.

> Well, technically speaking I can rewrite it, but no-one will mind.

Try that on multiple teams across timezones actively developing multiple branches, with big merges on a weekly basis.

"Rewrite module X" never happens. Even if you have a healthy suite of behavioral tests, it will still feel brittle because rewriting large sections of code will inevitably bite you in the ass.

And no you can't say "you're merging main into your branch? your responsibility."

Re: How to Write Unmaintainable Code (1999)

#52

Post by JoeCoder_ » Fri, Sep 18, 2015, 2:16 PM UTC

I once worked with a programmer who would not indent any of his code. "It makes it go faster" he said. Wrote all of his code in Windows Notepad too.

Re: How to Write Unmaintainable Code (1999)

#53

Post by kingosticks » Fri, Sep 18, 2015, 2:24 PM UTC

vog wrote: post #5

> 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?

My colleague does this and he is the main user of our office printer by far. As a driver writer, every now and then he'll print a few parts of the hardware source out in minute font and proceed to annotate/highlight it. He then files it away under his desk in the folder for that version. I'm happy in the knowledge that should our fileserver and backups spontaneously explode, we have a semi-versioned copy ready for someone to just type back into the computer. But in seriousness, it seems to work for him.

Re: How to Write Unmaintainable Code (1999)

#54

Post by macca321 » Fri, Sep 18, 2015, 2:36 PM UTC

tempodox wrote: post #45

deckar01 wrote: post #37

Earlier quoted context omitted.

Write tests that ensure each subroutine is called with specific parameters, so that functionally identical modifications cause the test to fail. Any change to the code now requires a change to several tests.

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. make the difference between these explicit.

Re: How to Write Unmaintainable Code (1999)

#55

Post by DCoder » Fri, Sep 18, 2015, 2:41 PM UTC

roel_v wrote: post #33

DCoder wrote: post #19

Earlier quoted context omitted.

To be fair, an IDE is not geared at auditing and it would be much more painful to do freeform annotations in it. Circling problematic areas, drawing connections between variables/functions, making handwritten notes in the margin... all that is easy on paper and requires workarounds/other programs on a PC.

I can see that, but how does one work through 5000 pages? I'd shoot myself in the head before the end of week 1 (metaphorically speaking). And I guess they used a combination of digital/analog methods, but still since the GP asked - that guy must've spend weeks studying printed source code...

As I see it, the auditor's job is to analyse the system thoroughly, not to skim some areas of it. Looking through 5000 pages worth of code on a computer screen would also be quite a challenge, even with the interactive aids you get from an IDE.

Tangent: speaking from personal experience, sifting through an existing foreign code base is a really exciting task for some people, figuring out what makes it tick and how the pieces fit together can be fun. Granted, I was reverse-engineering a closed-source product, not reading its actual source, but that was even more fun :D Come to think of it, the tool I used for that, IDA Pro, has some interesting features that IDEs don't, such as graphical representations of function call graphs [1] and function basic blocks [2]. It would be interesting to see what a creative person could do by integrating those into a regular IDE.

[1] http://scratchpad.wikia.com/wiki/Reverse_Engineering_Mentori...

[2] https://www.hex-rays.com/products/ida/tech/graphing.shtml

Re: How to Write Unmaintainable Code (1999)

#56

Post by aidenn0 » Fri, Sep 18, 2015, 3:27 PM UTC

bazzargh wrote: post #26

Someone wrote: post #11

They 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 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.

Re: How to Write Unmaintainable Code (1999)

#57

Post by littletinman » Fri, Sep 18, 2015, 3:37 PM UTC

This should be renamed to: "Common red flags to look for in merge requests and code reviews" and handed to every rookie, mid-level, and senior developer on your project!

Re: How to Write Unmaintainable Code (1999)

#58

Post by omouse » Fri, Sep 18, 2015, 3:42 PM UTC

littletinman wrote: post #57

This should be renamed to: "Common red flags to look for in merge requests and code reviews" and handed to every rookie, mid-level, and senior developer on your project!

Depending on the team you can get away with some of these. Have a manager/PHB that actively discourages unit testing? You don't need to commit your unit tests or write them at all! No one fixes an instance of copy/paste coding? Great, now you too can be efficient by copying and pasting everywhere. No one uses a code formatter or uses different formatting styles? Good! Now your style can shine!

These are all good red flags to check for in existing code bases before you join a team. If you see them, chances are their code review process is poor or non-existent and you'll be fighting a battle against crap code every single day.

Re: How to Write Unmaintainable Code (1999)

#59

Post by littletinman » Fri, Sep 18, 2015, 3:47 PM UTC

omouse wrote: post #58

littletinman wrote: post #57

This should be renamed to: "Common red flags to look for in merge requests and code reviews" and handed to every rookie, mid-level, and senior developer on your project!

Depending on the team you can get away with some of these. Have a manager/PHB that actively discourages unit testing? You don't need to commit your unit tests or write them at all! No one fixes an instance of copy/paste coding? Great, now you too can be efficient by copying and pasting everywhere. No one uses a code formatter or uses different formatting styles? Good! Now your style can shine! These are all good red…

Looking through the codebase for these to assess the teams review health is a fantastic idea!

Re: How to Write Unmaintainable Code (1999)

#60

Post by omouse » Fri, Sep 18, 2015, 3:50 PM UTC

vog wrote: post #5

> 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 did that at my first full-time development job. There was a 50 line method to refactor and it was making calls to some other methods so I printed maybe 5-6 pages of code. It helped to get away from the computer because I could focus only on the logic that I was refactoring rather than worrying about making tests pass or seeing it work in a web browser.

It's easier to solve a problem when you remove all the fluff and noise. On the other hand, you won't know if you have a good solution until it's implemented. A bit of a trade-off.