Re:80 chars per line is great
by VLM on Monday March 25, 2013 @11:15AM
(#5437402)
I recently switched from 80 to whatever will fit (oh, 120 or so) on certain projects.
Its an extremely personal decision because it depends on the exact interface of your skill level as a programmer in general, your skill level with that particular language, your skill level in the business problem domain, AND your own peculiarities WRT to the kind of errors you make.
Given the exact workload I'm being paid for at this time I do NOT make "line" level errors or even "small block" errors but instead get tripped up on crazy "business logic" and big architectural issues. So I am better off at this moment with longer lines showing more "big picture" than with clear little lines.
What I'm getting at is on recent projects I've been making more mistakes with "which blocks of changes need to complete transactionally/atomically based on crazy business logic without causing race conditions" rather than "I need to make it really clear I'm adding these two numbers as opposed to concatenating two strings" or whatever.
This tradeoff of width vs length varies for me, project by project based on actual requirements.
Personally I think this helps "those who come after me". If you see long complicated lines that's a warning that you should tread lightly there and there's probably something complicated at the "vertical" big picture level going on, so I had to make the "horizontal" look icky to make it fit. If I'm just squirting out blah blah code and hitting enter every 20 characters you can safely assume at the big picture there is nothing very complicated going on.
A good (fine arts oil) painting analogy is which is better, portrait or landscape canvas? Well, it depends on the scene. Maybe you personally are only commissioned to paint portraits, well then...
Its an extremely personal decision because it depends on the exact interface of your skill level as a programmer in general, your skill level with that particular language, your skill level in the business problem domain, AND your own peculiarities WRT to the kind of errors you make.
Given the exact workload I'm being paid for at this time I do NOT make "line" level errors or even "small block" errors but instead get tripped up on crazy "business logic" and big architectural issues. So I am better off at this moment with longer lines showing more "big picture" than with clear little lines.
What I'm getting at is on recent projects I've been making more mistakes with "which blocks of changes need to complete transactionally/atomically based on crazy business logic without causing race conditions" rather than "I need to make it really clear I'm adding these two numbers as opposed to concatenating two strings" or whatever.
This tradeoff of width vs length varies for me, project by project based on actual requirements.
Personally I think this helps "those who come after me". If you see long complicated lines that's a warning that you should tread lightly there and there's probably something complicated at the "vertical" big picture level going on, so I had to make the "horizontal" look icky to make it fit. If I'm just squirting out blah blah code and hitting enter every 20 characters you can safely assume at the big picture there is nothing very complicated going on.
A good (fine arts oil) painting analogy is which is better, portrait or landscape canvas? Well, it depends on the scene. Maybe you personally are only commissioned to paint portraits, well then...