consistency over elegance

Usually developers spend more time on reading code rather than writing code. Consistency makes the code more readable.

Is it better to do things consistently wrongly than erratically well? Maybe not in life but when it comes to software. Here are my ratings:

:-D consistently well
:-) consistently wrongly
:-| erratically well
:-( erratically wrongly

Consistency wins.

Sometimes particular anti-pattern consistently infests whole application. There is no point in throwing bodies in refactoring it because the cost may be little compared to the gain. Anti-pattern may be well-known and in general not extremely harmful. Refactoring it in one place may seem decent but introduces inconsistency with all the other places. I value overall consistency over single-shot elegance.

There’s no rule without exception, right? Sometimes the goal is to implement something in completely different way, to implement an eye-opener, to create “the new way”. Then one could relay on distributed-refactoring spirit of the team and let others join refactoring feast. If the spirit evaporated :(, one could always make using “the old way” deliberately embarrassing or just frikin’ difficult.

Consistency rule helps in all those hesitations a developer has on daily basis. Ever felt like two-headed ogre from Warcraft?

“This way, no that way!” – the heads argue.

Yes, you can implement stuff in multiple ways… My advice is: know your codebase and be consistent. Choose the way that was already chosen.

Being consistent is important but not when it goes against The Common Sense. Obviously ;)

6 Responses to consistency over elegance

  1. Elliot says:

    Which head should I slay?
    I am leaning towards elegance… Why?
    Refactoring will fix it if you favor something for it’s elegance. If you favor consistency – you DON’T have a choice.

  2. Nony says:

    I do understand that there might not be that much mkread for Linux usage, but to drop the platform entierly (hopefully i’d understood that wrong?) is just plain sad. X-plane should be able to be played at Linux, as it is a growing framework usage and more and more will convert as the distros gets better and better (ref. Ubuntu, Mint, Fedora etc.)I’ve tried XP10 on Linux and I can say for sure that it has far better performance than Windows 64bit has (though no support for 64bit yet), so it would be a shame to not have further updates to Linux if so inteded.What about MAC, is there a hole lot of selling mkread shares there? I guess there is, but I would bet there is not more than Windows, am i right?I do hope I got this all wrong and we will still see X-plane for Linux in the future as well..PS..Thanks a bunch for the Hat On

  3. Emmilse says:

    Thanks for the insights, Ben. Hate to rueqest features using your nice blog, but here we go A few of us DONT use joystick mapping to drive X-Plane, but existing datarefs. (the ones indicating yoke deflection and so on).We already suffer some issues (like X-Plane thinking there’s no Joystick and drawing a nice cross for flying with the mouse, or, as far as I can tell, different settings (like linearity) not being applied to our inputs, so wanted to ask if at least we will be keeping same functionality.Essentially our cockpits talk with X-Plane using a TCP connection and a plugin, which exposes our HW to all data refs. For us, elevator is no different than throttle, so would rather keep using a dataref rather than emulating a Joystick.

  4. Ray says:

    techniques for safely chgnae existing code. We have gathered these techniques in a workshop called Working FAST and safe with existing code, but we also teach them on site as needed. The key point of the techniques is to take very small

  5. Whoa, whoa, get out the way with that good information.

  6. That’s really thinking of the highest order

%d bloggers like this: