

Ask HN: How do you keep your code elegant? - takinola

I would love to have folks share tricks they use to keep their code elegant.<p>A little background for this request.  I am a self-taught hacker and when I work on projects, I typically spend a bit of time thinking through the structure of the code, breaking it down into functional modules, figuring out a good database schema, etc.  In order not to get carried away with over thinking the architecture, I usually set a time limit on how long this process can take and almost always end up with a very simple, straightforward design that gets the job done efficiently (enough) and, dare I say, elegantly.<p>The problem comes when the project hits the harsh light of day and I start getting feature requests from users that I never anticipated.  Once I start implementing these new features, I discover the code is no longer as streamlined or straightforward, the database schema is now less than ideal and I need to rely more and more on documenting my code instead of being able to trust that the flow is self-evident.<p>Now, don't get me wrong.  I'm pragmatic enough to realize users do not give a shit about the code and just want stuff to work but I care.  I'll throw in a hideous hack if that's what it takes but I like beautiful code and even if I am the only one who knows what's going on behind the scenes, I get a small sense of satisfaction knowing just how well it all hangs together.<p>So, let's hear your tips on how to ensure your code stays beautiful.
======
kls
The life of a developer goes through several phases, generally over-
engineering is one of them, then generally comes clever, many times developers
never get past clever and start to confuse it with elegance, but clever code
is not by itself elegant, the mark of elegance is simplicity, when code is
simple it becomes elegant, when it is simple and clever it is elegant. But if
you have to choose between one or the other choose simplicity. Code that even
a novice can see the beauty in the simplicity of it (and understand it) is
where true elegance lies. It takes a true craftsman to take something complex
and make it simple. That it what we do every day, we take complex processes
and simplify them via automation and association. When one realizes the same
principle applies to the development of their code, they then start down the
path of writing truly elegant code.

Simple code is decoupled, simple code does not have tight dependencies, simple
code is well organized and simple code does not rely on too much abstraction.
If you strive to achieve those few things you will be a better developer than
a significant portion of your peers.

decoupling code allows you the ability to extend the system without having to
go back and modify existing code.

Avoiding as many tight dependencies as possible allows you to change portions
of the code base without having the ramifications of those changes leak out
into other areas.

Well organized code allows new developers to find what they are looking for,
it helps document itself. Part of good organization is adhering to standards
and best practices.

Relying too much on abstraction means that you can't see a complete picture of
the code without understanding multiple layers. Abstraction, when used
properly, allows you to reuse code which is a good thing, but it comes at a
cost, it sacrifices conceptualization. Too much abstraction and the system or
a portion of it cannot be easily conceptualized in the mind. It also creates
tight dependency among components that sit on top of abstracted layers. It
should not be avoided, but no problem can be abstracted away, if the code in
question cannot be reused there is no reason to abstract it, rather
componentize it into discreet blocks, so that it can be conceptualized as a
black box.

------
smattiso
This is an art and over time you will get better. But I suspect there is no
"solution" and this is part of being a programmer :)

I mostly do OO programming, so I'll speak to that. In general there is no
magic bullet and the only way to guarantee code quality over time is to
refactor. That's just how it is. That being said in practical terms there are
some ways you need to be diligent.

Resist the "oh it's just one more...." urge. Whether that means a new method,
data, condition, etc. If the scope of a class is increasing past what
originally intended then split it up! No need to go crazy. When a class is
becoming a PIT due to too much code or lack of flexibility then fix it. Don't
plan too far in advance. This is hard and the urge will be strong but don't
give in (unless the business demands it.. gotta make that $$$$).

When you encounter a situation where you clearly get a benefit by making
things more flexible. Do it. Refactor. Don't wait it will only get worse.

I struggle with this all the time. In my opinion don't think too much about it
and just do what feels right. You'll know.

------
please_no
>takinola What do you code in?

If C, use the the one your project uses the most.

Personally I love Allman style, but that is not what my friends use:
[http://www.freebsd.org/cgi/man.cgi?query=style&sektion=9](http://www.freebsd.org/cgi/man.cgi?query=style&sektion=9)

Pick one you like: <http://en.wikipedia.org/wiki/Programming_style>
<http://en.wikipedia.org/wiki/Indent_style#BSD_KNF_style>

------
hoka
Have you worked through any code katas? I find that the end 'solutions' are
generally elegant and working through the steps is a helpful way to get there.
Obviously your own work will vary, and you'll never have someone else's
solution to compare against, but many of the skills and methodologies should
carry over.

I think the original ones are the best, but if you don't know PHP (I wouldn't
say that I do), finding some in your language(s) of choice would be best.

------
greghinch
Learn Python. Copy people who are better than you until you understand why
they did what they did. Make mistakes. Ultimately, never be satisfied that you
know all you can in your field

------
beatpanda
Relentless refactoring.

~~~
SirPalmerston
Pretty much my life. So far, I've written an app in PHP and then rewritten it
in Python 3 times, each time making the code more polished and complete.

I don't think I'll ever finish it :/

~~~
shrughes
Rewriting is not the same thing as refactoring.

