Ask HN: What has heavily influenced your coding style?

When I started having to read other people's code, I realized that everyone needed to stop writing "clever" code.

Maintenance work. No more being clever with "elegant" OOP hierarchies and abusing generics. No more layers upon layers upon layers. No more DAL's and other hideous abstractions over the database.

Just the KISS principal. I'll take repetitiveness over obfuscation anyday.

I prefer compact coding (started with BASIC on a Tandy 102 laptop way way way back).

But it also needs to be readable/pronounceable: and it needs to be readable even on cruddy screens / bad printouts. No "i" and "j" for loop counters, for example: the compiler doesn't care how long you make your names, so I use things like "kt" or "ndx" (because typos happen, and fewer characters that still convey the same meaning is acceptable).

I also do my best to never write overly clever code. Shared another [HN](https://blogs.msdn.microsoft.com/oldnewthing/20170719-00/?p=...) [post](https://news.ycombinator.com/item?id=14810014) with a little commentary on G+ last night:

   Sadly - or, perhaps, happily - I can remember when I used to do wonky crap like this.

   Then I learned the axiom, "if you code as cleverly as you can, you are, by definition, not clever enough to debug it" (I think it's called Kernaghan's Lever - but I may be mistaken).

   Write code you can explain to a 4th grader. Or your grandma. If you have to stop and think about how clever it is, you are going to end up cleavering yourself with your feigned cleverness.

I agree with several other users on this thread about maintaining existing code. If you aren't already working in a position in which you have to modify code written by others, try to start fixing bugs or writing features for an open source project. In either case you should immediately see how frustrating it is to try to figure out why things in the code base are the way they are, and I think the best solution is not documentation but clear, clean code that self-documents, not with comments but with small focused recipe-like functions. Bob Martin's book Clean Code[1] is a quick read that makes clear how this can be done effectively. Martin Fowler's book[2] is another obviously good illustration.

The second thing that has really influenced my coding style for the better (making it clearer and easier to understand) is writing a medium-sized program using a strictly functional language like Erlang. This will force you to use global state less, to write functions in such a manner that the function itself includes all the information required to understand it, simply because global state cannot be used and everything on which the function operates must be passed into it explicitly via its parameters.

[1] Clean Code (Robert Martin) http://amzn.to/2uewcpB

[2] Refactoring (Martin Fowler) http://amzn.to/2vnD7vx

Learning functional programming has definitely changed the way I manage state. I tend to explicitly pass variable into functions and return them instead of just having them change some hidden State