Closed Poll: How to split long code lines
-
How do you handle long code lines like:
// This is a long code line which Discourse will probably break in two. Imagine is only one PoolableConnectionFactory poolableConnectionFactory = new PoolableConnectionFactory(connectionFactory, pool, null, null, db.isReadOnly(), true);
- With a new line in the equal.
- With a new line in the parenthesis.
- With a new line in the equal and parenthesis.
- With a new line for every element indented in the parenthesis.
- I don't split long lines because in 2014 we have enough screen width to single line the bible.
- Other
Example for 1:
PoolableConnectionFactory poolableConnectionFactory = new PoolableConnectionFactory(connectionFactory, pool, null, null, db.isReadOnly(), true);
Example for 2:
PoolableConnectionFactory poolableConnectionFactory = new PoolableConnectionFactory( connectionFactory, pool, null, null, db.isReadOnly(), true);
Example for 3:
PoolableConnectionFactory poolableConnectionFactory = new PoolableConnectionFactory( connectionFactory, pool, null, null, db.isReadOnly(), true);
Example for 4:
PoolableConnectionFactory poolableConnectionFactory = new PoolableConnectionFactory( connectionFactory, pool, null, null, db.isReadOnly(), true );
-
Don't write them.
-
Don't create names that will result in such monstrosities in the first place?
-
Use an IDE that breaks lines automatically and stop worrying about them?
Filed Under: Pretty sure using an IDE is a blakeylaw!
-
try to avoid writing them in the first place, but if they are unavoidable handle them however the built-in auto formatter for the IDE in use for the project handles it.
-
If there are only a few arguments I try to keep everything on one line. If there are a ton, I put each argument on its own line. It makes debugging easier because C/C++ may give you a line number but absolutely won't give you a meaningful exception message if something goes wrong. It also makes compiler errors due to wrong parameter types (usually because I get the pointer stuff wrong, i.e. should I use arg, &arg, *arg, or **arg?) easier to pin down.
-
Don't create names that will result in such monstrosities in the first place?
This is a third party (Apache DBCP)
-
Eclipse does #2 but I like the more JS way of #4
-
I voted don't split long lines, because I'm young enough to have never used a computer with an 80 character line limit, but if it was really unwieldy I'd go with a new line for each argument
-
This is a third party (Apache DBCP)
Then one long line, to remind others (or yourself in 6 months) what a bad idea it was to use that particular 3rd party library?
-
It's pretty good actually, and I won't get rid of it only for this little nuance.
-
Thank you, a reasonable explanation.
-
Great... except that the standard libraries for Java or C# tend to have long names for functions.
-
If there are a ton, I put each argument on its own line.
It also makes reading easier.
-
A good solution for arg lists from Hades, courtesy of a former employer:
[code]
PoolableConnectionFactory connPoolFactory = new PoolableConnectionFactory(
connectionFactory
, pool
, null
, null
, db.isReadOnly()
, true
);
[/code]Filed under: trailing commas are a hazard to compilation
-
Also, Java is uselessly verbose here. C++ lets you say
[code]
PoolableConnectionFactory connPoolFactory(
connectionFactory,
, pool
, nullptr
, nullptr
, db.isReadOnly()
, true
);
[/code]Which would you rather read and maintain?
Filed under: said former employer also has a company-wide abbreviations dictionary
-
Is this the reason he's "former"? I would totally understand.
-
Is this the reason he's "former"? I would totally understand.
Actually, no, it isn't. They are the place I interned at for oh, 18months of work time spread over a few calendar years, and still get high marks in my book, coding style quirks and all. It's actually easier to type in an autoindenting editor than it looks at first glance, too.
-
Why are you retaining the information in the variable that it is a
PoolableConnectionFactory
? In virtually all sane usage scenarios, it's best to have the rest of the code only know that it is aConnectionFactory
. And I'd use a shorter name likeconnFactory
too, possibly even justfactory
(depending on context).There you go, saved 22–26 characters in one go!
(I'd also leave the whole thing up to a DI framework like Spring to actually build this sort of thing, for easier configuring and mocking and to stop polluting my code with stupid setup BS and headaches, but that's another matter entirely.)
-
A good solution for arg lists from Hades, courtesy of a former employer:
[code]
PoolableConnectionFactory connPoolFactory = new PoolableConnectionFactory(
connectionFactory
, pool
, null
, null
, db.isReadOnly()
, true
);
[/code]Filed under: <a>trailing commas are a hazard to compilation</a>
The evil ideas thread is over there.
-
My order of preference is roughly:
SomeLongTypeName var = new SomeLongTypeName(params);
followed by your #1, followed by #3, followed by #4. I'll switch to the next one in my list when I think it's still too wide (or I run against our obnoxious 80-char standard). I really dislike #2.
I don't have a problem with putting all the arguments on a single line (as in #3), but if I put a line break between two arguments I put a line break between all the arguments (getting to #4). (With an exception that if there are logical "pairs" of arguments, like an x and y coordinate or a begin and end pair to a C++ STL algorithm, I will put those on the same line.
I definitely don't like to split at 80 characters, but I think by like 100 or 110 it starts to get a bit unwieldy. But I also really like calling out parallel structure of consecutive lines where it exists, so that will make me more hesitant to break.
-
Putting the commas up front is ugly as sin. A better solution is for the language to just ignore a trailing comma in a list without throwing an error. I know Python and JavaScript allow that.
-
-
JavaScript allow that.
not if you want to be compatible with IE.
IE before IE9 barfed on trailing comma. IE9 issued warnings, or errors if it was in compatibility mode.
IE10 does weird things with trailing commas, including sometimes* replacing the entire array with
undefined
and don't get me started on IE11.... or Opera... -shudder-*well not exactly sometimes, if it's going to do it ti's always. has to do with a particular combination of compatibility level and document mode
-
Putting the commas up front is ugly as sin. A better solution is for the language to just ignore a trailing comma in a list without throwing an error. I know Python and JavaScript allow that.
Go requires it.
...I'll have to test this, but it seems like you'd wind up with null elements in the list, making using any kind of functional walking of arrays a total pain in the arse. If not, then it makes me wonder how the runtime handles arrays with intentional nulls.
Well, apparently it's fine with it: http://jsfiddle.net/5oka4xdr/
Huh. Still, no IE testing for me today... muahaha.
-
I would shorten the variable names (not the class name; I've found shortening type names can be counter-effective). Typically I use initialling; so the variable would become
pcf
.I wouldn't newline after the opening brace; I'd newline after commas in a way that makes sense to the meaning of the variables. I would also likely split the initialization and the declaraction on such a long type name. Typical target line width for code is 100 characters, hard limit 120 or so.
PoolableConnectionFactory pcf = new PoolableConnectionFactory(cf, pool, null, null, db.isReadOnly(), true);
That's 107 characters, acceptable on one line.
-
-
It's because of semicolon insertion.
<filed under: shifting the wtf>
-
-
-
Voted for #1, but #4 is my second choice.
-
I do a combination of 3 and 4 usually, like so:
[code]
PoolableConnectionFactory connPoolFactory =
new PoolableConnectionFactory(
connectionFactory,
pool,
null,
null,
db.isReadOnly(),
true
);
[/code]Depends on the language though, sometimes you can refactor it to be less hideous in less hideous languages.
Edit - also, commas in back damn you, although again, that seems to depend on what I'm doing - SQL select statements I put the commas in front..
-
Putting the commas up front is ugly as sin. A better solution is for the language to just ignore a trailing comma in a list without throwing an error. I know Python and JavaScript allow that.
It is; sadly, some language designers just aren't that bright.
Filed under: sometimes, the trailing comma is even required
-
If you really got such a long classname, I declare my variable up-front then assign it on the next line.
PoolableConnectionFactory poolfactory; poolfactory = new PoolableConnectionFactory(connectionFactory, pool, null, null, db.isReadOnly(), true);
Line-length soft limit is 100, next line is then indented until it matches the opening parethese.
If you got more parameters than that, reduce indent or start running, your choice.
-
-
-
You're really trying for @PJH to give you the "pedantic spelling nazi" badge, right?
But yes, you're right, more power to you. Next time I'll write "bracket" to see who responds.
-
Next time I'll write "bracket" to see who responds.
<koff>...
- [ Bracket
- ( Parenthesis
- { Brace
You've only got yourself to blame, since you called me over...
-
Yes, but I don't see a notification I got a new badge.
Dammit, JBert, you didn't flag my post!
-
Putting the commas up front is ugly as sin. A better solution is for the language to just ignore a trailing comma in a list without throwing an error. I know Python and JavaScript allow that.
PHP does for array items but not function declarations, which is fucking annoying.
As in:
$array = array( 'item', 'item', );
is legal, but this would not be:
$var = myfunction( 'arg', 'arg', );
Another fine inconsistency from Personal Hell Pit.
-
In a language that (presumably, based on those snippets) uses a semi colon to separate lines, that's just stupid.
Filed under Psychological Horror Programming
-
Putting the commas up front is ugly as sin. A better solution is for the language to just ignore a trailing comma in a list without throwing an error. I know Python and JavaScript allow that.
Did they fix newer versions of IE to allow trailing commas in javascript? Last I knew, trailing commas in arrays in IE results in an error. But I probably havent tried since IE8 or 9.
I don't know why I ask, I can just try it the next time I'm on a PC with IE 10 or 11
-
In a language that (presumably, based on those snippets) uses a semi colon to separate lines, that's just stupid.
Yes. Yes it is.
-
Did they fix newer versions of IE to allow trailing commas in javascript?
As far as I can see, yes, that's fixed in IE10.
-
As far as I can see, yes, that's fixed in IE10.
IE: catching up to other browsers years later.
-
-
I don't give a shit where it comes from. PHP had the opportunity not to pull that shit and did it anyway.
-
PHP had the opportunity not to pull that shit
What are the odds that would have happened?
Do you own one of those double-clawed PHP hammers? I really hope so. :)
-
Slim to none - but you gotta admit they did have the opportunity. And slowly and surely the language is becoming less WTFy. Just not nearly fast enough.