Apparently “ninja” is Japanese for “one who is invisible” and that sounds appropriate to me. I’ve thought of ninja coding as going and changing something as the original author would do. The idea is to leave no indication, other than a commit history, that you were there.
The same function can be written in all sorts of ways: tabs vs spaces, where to put your braces, identifier naming schemes, what sort of loops to use, how to write comments and many more. Exactly how to write code can be the centre of all sorts of arguments. However you write it, I think consistent code is generally better than inconsistent code. Trying to understand what code is doing and how it is doing it is easier if it does things in one way.
It probably doesn’t hurt too much to have a line or two of “foreign” code in the middle of a function.
It only take a few extra moments to understand that, say, while the start of the function refers to
wordCount the middle uses numberOfLetters. Both are totally understandable. However if different
people keep making changes to more styles pile up. What was consistent becomes a bunch of disparate pieces.
I prefer to stop it before it starts.
I think this is more obviously a problem when thinking about non-coding examples. If you’re updating some documentation it’s not going to help if jumps between some dry paragraphs and others that are full of jokes. If you’re making 3d models then it’s better to pick sharp corners shapes, smooth rounded corners, or a good reason to pick one or the other. While the output of our code is very important we spend a lot of time interacting with the code itself, so that is also important.
For me the ideal solution is to have coding standards that look at the best way for the team to write code for this project. However, as I said before, this can be the centre of all sorts of arguments. I think the first solution is to be respectful of how the existing code is written. Go in, fix the bug or add the feature without changing anything else. Make it look as the original author would have. Refactoring code style or to make general improvements is valid but separate. Maybe it should be done on a new ticket or maybe the same ticket. However it should be, at least, a different commit. That way someone else can understand: this is the fix, this is a style change.
Awful code
Maybe you’re in a situation where the existing code is just too awful to serve as a guide. If it’s just where to put the braces you might need to bite the bullet but if it is truly terrible then, commiserations, I know there is code like this.
If it’s a legacy code problem then that is something that can be dealt with over time. If your schedule allows it would be great to add tickets to refactor the code. It’s much easier to debug and update good code rather than bad, really it is. If your schedule doesn’t allow for a timeout then it can be updated piecemeal. Maybe you can update a class, function or even just part of a function. If the code is awful then having it hanging about will continue to be a problem. I’ll talk about refactoring later but as a quick tip, do it in small steps rather than a single leap.
If it’s an ongoing problem with someone writing awful new code then that is probably a harder problem. Some people have very different ideas about what good and bad code look like. Some people don’t care what code looks like only whether it functions correctly or not. Some people just don’t seem to care. For me having code that can be used and understood by everyone is important. If the code works but can only be changed by one person that a big bottleneck and a big risk. If someone is writing code like that unnecessarily then they’re not really doing their job.
Leave a Reply