
Ask HN: What has heavily influenced your coding style? - forkLding
Aside from books, has there been any major events or issues that stemmed from your code while in production, etc that has shaped how you code and how do you think you improved from there? Generally curious and want to learn more.
======
technofire
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](http://amzn.to/2uewcpB)

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

------
warrenm
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=...](https://blogs.msdn.microsoft.com/oldnewthing/20170719-00/?p=96645))
[post]([https://news.ycombinator.com/item?id=14810014](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.

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

------
101000010101
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

------
flukus
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.

