80? 100? 120? Something else? Personal preferences preferred over some standard.
I typically don’t worry about it as there’s this miraculous thing in most code editors called word wrap.
When I used to use punched cards, it would be 80 characters
When I used COBOL, I only used 7-72 (OK, I used 73-80 to comment lines )
I generally prefer however many characters it takes to finish a line of HTML or CSS. So that varies.
depends what i’m doing if i have to split a query for example i will do it at specific points rather than just hit a number and press enter. For an sql query for example i’d break when the function changes.
eg
"Select field1 from table Where something ="something else" AND this = "that" Order by id DESC Limit 0,10
rather than
"Select field1 from table Where something ="something else" AND this = "that" Order by id DESC Limit 0,10
Both work the same but i can read the top one much quicker if i have to work out why something isn’t working or what the query is doing. That was just something simple but once you output 15 fields and have 4 left joins on it is even harder to read in a single line.
Just my preference.
Now SQL is a whole other animal entirely. I used to do similar to what you did, but I learned from @r937 many years ago that if the objects/conditions are on their own lines, it makes it easier to find errors. So SQL would be something like
SELECT table1.field1
, table1.field2
, table2.field3
, table2.field4
FROM table1
JOIN table2 ON (table1.PK = table2.PK AND
table2.field5 = 'ABC')
WHERE table1.field5 = 'DEF'
AND (table2.field6 > 1 OR
table1.field7 <100)
ORDER BY PK DESC
LIMIT 0, 10
I like doing similar for longer / nested conditionals too eg. I find it much easier to read
if ( ( ($a == "a")
&& ($b == "b") )
|| ( ($c == "c")
|| ($d == "d") )
|| ($e == "e")
) {
than I do
if ( ( ($a == "a") && ($b == "b") ) || ( ($c == "c") || ($d == "d") ) || ($e == "e") ) {
I’ve honestly never thought about it. I just wrap it (if I can) when it gets to the point where it looks too long. Similar to @Mittineague’s example.
ew. Word wrap in code is evil!
It’s not often I have conditionals that long, so it’s rare for me to do that.
But I do that for big arrays, then for big multidimensional ones I end up indenting them like a file tree or it gets too confusing.
I generally try to keep things within screen width for easy reading.
I also do that for long / nested arrays.
I do prefer word wrap at times. I’d rather have
var text = "one long line of text that wraps to lines";
than
var text = "one long"
+ "line of"
+ "text that"
+ "wraps to"
+ "lines";
or
var text = "one long";
text += "line of";
text += "text that";
text += "wraps to";
text += "lines";
It is interesting to see all the styles that folks find useful and/or easy to read. Mostly I tend to be pretty narrow-minded… if it doesn’t look like how I do it, I find it hard to read
My code and comments are only limited by either the end of a statement or the right side of my editor. I do not like right/left scrolling, whether it’s code or any other document. So for me that’s about 1000px. I have an aversion to extra spaces, semi-colons and carriage returns used just for formatting, but tabs used to indent is perfectly fine. So CSS attributes each carefully written on its own line with that trailing extra semi-colon on the last one… I have to stop now, my blood pressure is rising!
Same here… intended and indented (muhaha) line breaks are indeed much nicer than automatic wrapping or scrolling.
Another case where I’d usually have a break is longer chains… I’d even choose the syntax accordingly to better reflect the structure, e.g. consider this jQuery chain
$('#foo')
.show()
.css({
width: $(window).width()
})
.click(function() {
alert('bar');
});
which is much nicer to read IMHO than
$('#foo').show().css('width', $(window).width()).click(() => alert(bar));
But this is quite harmless, of course… when it comes to, say, ORM querybuilder chains you’re rather lost w/o line breaks (just like with SQL, obviously).
This all being said, I do like and overuse the ternary operator. :-)
It depends on how many conditions.
More than 3, I split on separate lines.
Less, I use a single line.
For programming languages everyone agrees that shorter lines are easier to read.
It’s painful to watch people obscure long lines to appease a linter though, It’s the kind of thing I think is best left up to the developers judgement. Some times a longer line is best.
With the smart debugging available I can read anything. I don’t really think it matters. Having said that if a project has defined standards use those otherwise just leave it up to your best judgement.
This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.