HN Explorer

Some programming principles I have been living by

14 points by erikpukinskis ↗ HN
Do as much as possible in one language

Do it inside a module with a clearly described interface

No modules bigger than 150 lines or so. They should read like a chapter in a book

Prune data structures as much as possible at interfaces

Code is deployed with a realtime editor

Don't break the debugger

Stick to functions and literals. If you want to use a fancy control structure, it's fine, just do it behind a function with an understandable name and a clear interface

Address the widest possible market, and use whatever backwards technology you must to make it possible

Try to keep things imperative, even if you have to reorganize your functions so it reads well. Only use declarative interfaces where you truly need meta control, like composing things that can't just be concatenated, or optimising a pipeline

10 comments

[ 3.0 ms ] story [ 32.1 ms ] thread
trcollinson
On the face of it, your list seems quite reasonable. I like it. What is your one language of choice? Do you have any examples you'd share that demonstrate your principles in action?
twangist
You must only read books with very short chapters.
meric
>> Do as much as possible in one language

>> No modules bigger than 150 lines or so. They should read like a chapter in a book

>> Code is deployed with a realtime editor

>> Address the widest possible market, and use whatever backwards technology you must to make it possible

I'm going to guess, your one language is javascript? I write Node.js too and your list is a reasonable list for "A list of Node.js programming principles".

S4M
Mine (a bit shorter and less committal):

- Try to have as little side effects as possible

- Keep the number of data structures I use in the same project as small as I can.

ely-s
My guiding principle is to code something so that you only have to code it once.
TurboHaskal
- Don't worry about extensibility and configurability.

- Use sane defaults.

- Treat bad documentation as a blocking bug.

- The tool you look for probably exists already and it's not going to get better just because you rewrite it Rust / Go / Node.

- Abstraction should make things easier. Abstraction for the sake of abstraction is obfuscation.

osullivj
Yep - premature abstraction is just as bad as premature optimisation.
osullivj
"Listen to the system". When I'm debugging, I always being all kinds of preconceptions about possible root causes to any issue. Those preconceptions often stop me reading and understanding error messages properly. So I take a deep breath, and try to really read the error messages, and listen to what the system is telling me.
osullivj
"Evenly distribute complexity". This is hard to do. As a new codebase takes shape it is hopefully well modularised. But inevitably there will be one or two modules that become knotty concentrations of complexity. The form of the code is telling you something about your analysis of the problem space.