Hacker News new | past | comments | ask | show | jobs | submit login

The complexity of tests tends to go up faster than the complexity of the functions under test.

One of the thought experiments I use for teaching testing is to remind them that nobody wants to read your code. The next person to read your test is probably going to be reading it because it’s failing. They are in effect already having a bad day. Don’t make it worse. They will assign that negative emotion to you.

This has started to affect all of my design thinking. I’m probably only reading your code because I’m trying to hunt down a bug (or my attempt to add new functionality has failed spectacularly). Every time I run into a function that contains code smells, I have to stop long enough to figure out if those smells are the bug I’m looking for or something else. In a particularly bad codebase, like the one I inhabit now, by the time I finally find what I’m looking for, I no longer recall why I was looking for it in the first place.

This is not good code. It’s shitty code written by people who aren’t emotionally secure enough to write straightforward code. Or are running from one emergency to the next, all day every day. Or both. Or are young developers just copying what they see around them.

All interesting points, the reason I hate class clutter is especially because of debugging/understanding. I don't want to have to spend a long time building a mental hierarchy of classes and what they do just to figure why a link doesn't have the right URI. Essentially, people use classes to achieve magic code. Code that's very, very convenient when it works, but is monstrous to debug when it doesn't. Especially if the code isn't something you're familiar with.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact