The Bathroom Wall of Code

  1. Use the internet to understand the problem domain and then write your own code, knowing exactly what each line does

I sort of touched on this in “when understanding means rewriting”. It does force you to touch every line, and that’s a de-facto code review…

http://www.codinghorror.com/blog/archives/000684.html

Rock on, TwitOfTheMonth. Best comment yet.

@steve
http://www.refactormycode.com/

I’d suggest putting a big, fat ‘disclaimer’ above your code, preferably in bright red saying “Every time you c/p this, a kitten gets gutted with a blunt machete. Also, your app will have a security hole the size of Mount Blanc.”

Then again, people don’t really care much for kittens any more these days.

CBC has problems with openSSH: http://news.zdnet.com/2100-9595_22-303182.html

Pop quiz: When did Jeff jump the shark? Was it the password screw up? The xss vulnerability? Or this latest encryption misconception?

What is worse than that? Not sure.

Not learning from your mistakes is the worst of all, I’d say.

http://www.codinghorror.com/blog/archives/000300.html

“When I interviewed the surgeons who were fired, I used to leave the interview shaking,” Bosk said. “I would hear these horrible stories about what they did wrong, but the thing was that they didn’t know that what they did was wrong. In my interviewing, I began to develop what I thought was an indicator of whether someone was going to be a good surgeon or not. It was a couple of simple questions: Have you ever made a mistake? And, if so, what was your worst mistake? The people who said, ‘Gee, I haven’t really had one,’ or, ‘I’ve had a couple of bad outcomes but they were due to things outside my control’ – invariably those were the worst candidates. And the residents who said, ‘I make mistakes all the time. There was this horrible thing that happened just yesterday and here’s what it was.’ They were the best. They had the ability to rethink everything that they’d done and imagine how they might have done it differently.”

"@steve
Ask Jeff, maybe he’ll create one someday :)"
In about six to eight weeks I guess!

Skizz

“it sure would be nice if someone could perform a grep replace …”

Actually it would not.

Some people in thedailywtf.com claim that they’ve seen code copied from that website in code they’ve been working . . . irony, as thedailywtf.com is a wonderful repository of how to NOT do things in software development. :slight_smile:

You’d actually not want the grep/sed (why is it called a grep?)

What you’d actually want is for the most critical bits of documentation to automatically appear in-your-face when reading whatever information.

This is a bit like wishing for drunk drivers to automatically get visuals of the injuries they might inflict and the grieving families etc.

Oh wait. I suppose this stuff is already there. Google ‘ECB’ or ‘ECB +Encryption’ and you’d have all the info you need.

What it boils down to: the problem is not the code being bad. The problem is copy/paster being bad.

  1. Thou shall always use time-stamps and unique message counters to avoid replays.

Where a counter suggest incrementing numbers. From 20 years of IP stacks we know that this is not the most secure idea. Use random ID’s

You’d actually not want the grep/sed (why is it called a grep?)

What you’d actually want is for the most critical bits of documentation to automatically appear in-your-face when reading whatever information.

This is a bit like wishing for drunk drivers to automatically get visuals of the injuries they might inflict and the grieving families etc.

Oh wait. I suppose this stuff is already there. Google ‘ECB’ or ‘ECB +Encryption’ and you’d have all the info you need.

What it boils down to: the problem is not the code being bad. The problem is copy/paster being bad.

  1. Thou shall always use time-stamps and unique message counters to avoid replays.

Where a counter suggest incrementing numbers. From 20 years of IP stacks we know that this is not the most secure idea. Use random ID’s

This is a bit like wishing for drunk drivers to automatically get visuals of the injuries they might inflict and the grieving families etc.

It might have been clearer to say it like this: “Thats much like wishing everybody grows a common sense overnight”. It’s just not gonna happen.

Responsible jobs require responsible people. You can’t take the risk out of life without ending life. Things can only be simplified to a certain level and no further.

Attitude: deal with it, not “patch” or “mask” it

Okay, not everybody is responsible for every piece of code. When you actually promote that philosophy, what you really get is that nobody is responsible for any piece of code.

The responsible people are the author and the reviewer(s). And the author more than the reviewers, because reviewers usually expect that the author did something basically sensible, as the baseline for a review.

When I write a bug into the code, I did it, not the whole team.

-Max

  1. Thou shall always use time-stamps and unique message counters to avoid replays.

Where a counter suggest incrementing numbers. From 20 years of IP stacks we know that this is not the most secure idea. Use random ID’s

First, I think you mean TCP, not IP. Secondly, you would be using encryption and authentication, so hopefully you do not need to protect against the things the encryption-less TCP mostly unsucessfully has to try to protect against.
Thirdly, the point of it is to be able to know which data is outdated, so it has to be monotonically increasing. Which e.g. TCP sequence numbers are, even if they increase by random (small) amounts.

You don’t need to peer review everything committed in the code base as long as you peer review every critical pieces of code (pretty much everything related to security).

As long as you test the features and they work, if it works why bother reviewing every single line of code (unless you don’t test properly).

When posting code, also post your unit tests. This way the programmer copying your code can see if your tests cover their scenarios. If not they can add to the test and make sure that your code works for them.

{6230289B-5BEE-409e-932A-2F01FA407A92}

This is one of the main reasons I prefer open source libraries to random code snippets. Open source code is tested and updated, nobody updates or maintains code snippets.

Yep that works: http://blogs.fsfe.org/tonnerre/?p=24

Blind trust in valgrind - the Debian OpenSSL vulnerability

Open source arguments are so boring…

Hi Jeff

Great piece as always!

Just some musing, this quote:

"I mean us – the entire team. The onus is on us, as a team, to vet every line of code at the time it is contributed, and constantly peer review each other’s code. It’s a responsibility we shoulder together. Nobody owns the code, because everybody owns the code.

Yes, I failed. Because the team failed. "

Brillianty ilustrates why communist/socialist state could not prevail!

Everybody owns it, so nobody owns it; whereas each and everyone should put great care in nurturing it so that it could become ideal.

  • for ‘it’, substitute ‘the state’ or 'the code; - see how it all makes sense?

:wink:

Have a great day!

MD

Blind trust in valgrind - the Debian OpenSSL vulnerability

I think Jon’s point is that code absorbed from a living open source project is a much nicer bathroom. A random code snippet from a random website is certainly a dive bar sort of bathroom…