|
And at one point some person will need to print a piece of it to try to understand your logic.
John
|
|
|
|
|
I'd have to get up and walk around a couple of cubicles to get to the printer, so I hardly ever print source code.  Width of the screen minus any toolscreens in the IDE is my line length limit.
|
|
|
|
|
I used to limit the length to 80 charactes so I could print the code. I haven't printed a single line of code in several years, and now I am a little more relaxed about that rule. I still try to keep most lines under 90, but 2 or 3 extra chars won't do any harm.
|
|
|
|
|
Usually my lines are rather short, I tend to split up lines so it becomes more readable, like this:
int someValue = dbConnection.CreateSomeStatement().Execute().Value
becomes
Statement stmt = dbConnection.CreateSomeStatement();
Whatever foo = stmt.Execute();
int someValue = foo.Value;
Of course that's not always the case, but you get the idea.
Same for some if-blocks:
if (foo != null && foo.HasSomeFlag() && foo.HasSomeOtherFlag && foo.FooFooFoo())
becomes
if (
foo != null &&
foo.HasSomeFlag() &&
foo.HasSomeOtherFlag &&
foo.FooFooFoo()
)
regards
modified 12-Sep-18 21:01pm.
|
|
|
|
|
I would likely make the first one:
int someValue = dbConnection.CreateSomeStatement().
Execute().Value ;
(leaving the dot at the end rather of one line rather than putting it at the start of the next.)
And the second one:
if
(
foo != null
&&
foo.HasSomeFlag()
&&
foo.HasSomeOtherFlag
&&
foo.FooFooFoo()
)
so the &&s stand out. I like a lot of whitespace.
|
|
|
|
|
Also good if you get paid per line.
|
|
|
|
|
|
I try to have all my code visible without any horizontal scrolling.
To do this and still have pretty big lines I use a wide 22" monitor and lowered my font size to 8 (on VS 2008).
With this I find myself having all my code within the monitor limits without having bother about it (most of the times...  )
|
|
|
|
|
What about the poor guy who is 55 and wears glasses that needs to maintain your code. Maybe you yourself?
|
|
|
|
|
What about him?
I'm not saying that our team works on small monitors with high resolutions, I'm saying that we use big monitors, currently 22" & 24".
My current configuration is 1680x1050 on a 22" DELL monitor.
Sure the resolution is high but as the monitor size is also above the usual you keep seeing thing on a normal size, no problem.
I can tell you that connected to the same computer I also have a 19" DELL with a resolution of 1280x1024 and I don't see any difference between them on the font size... I only have more workspace area on the 22" monitor.
Cheers!
Alex
|
|
|
|
|
I stuck to two general rules in programming:
1) One Statement per line (I don't usually make those insane multipurpose do all lines)
2) Descriptive Variable names.
Part 1 decreased column size and part 2 increases it. In code maintainability is more important that printable readability imho.
Need software developed? Offering C# development all over the United States, ERL GLOBAL, Inc is the only call you will have to make.
If you don't ask questions the answers won't stand in your way.
Most of this sig is for Google, not ego.
|
|
|
|
|
Ennis Ray Lynch, Jr. wrote: One Statement per line
Yes, but...
What's a statement?  Isn't a compound statement a statement?
I don't stick to one line per statement (as is well-documented).
|
|
|
|
|
Welcome to the Year of the Ox !
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
"How do you find out if you're unwanted if everyone you try to ask tells you to stop bothering them and just go away?" - Balboos HaGadol
"It's a sad state of affairs, indeed, when you start reading my tag lines for some sort of enlightenment. Sadder still, if that's where you need to find it." - Balboos HaGadol
|
|
|
|
|
Since I spend a great deal of my time working in stored procedures, I take the opportunity when I deem it necessary to update them for readability.
I DETEST having to scroll to the right to see what columns are being selected and then scroll back to the left to see what the query conditions are.
I especially get annoyed when I see an inline case statement in a select statement and it is all on one line.
Tim
|
|
|
|
|
I'll let code stretch out, but I do limit line length for documentation.
|
|
|
|
|
I always limit to between 80-100 chars maximum per line. Doesn't matter if it is being printed or not purely because it makes reading the code much more bearable.
Scrolling the screen horizontally for long lines breaks your chain on thought so keeping all the code right in front of you is better!
|
|
|
|
|
Paul Betteridge wrote: Scrolling the screen horizontally for long lines breaks your chain on thought so keeping all the code right in front of you is better!
I agree, although at times I may go to 120 chars just to be wild and crazy. 
|
|
|
|
|
Hi!
I answered sometimes yes, sometimes not.
Mainly, this depends on the situation: sometimes you may be able to break up a long line into multiple statements, but sometimes (such as with long function or variable names, etc.) it is difficult. I also don't like breaking up strings onto separate lines, as that requires additional concatenation, which is wasteful just for making the code appear prettier.
Anyway, I don't use a predetermined size, I go by what it is I'm working on: in C#, it can be simple to use a particular length, but in XML, for example, i may want everything on one line, to make it easier to find stuff later on.
Schmuli.
|
|
|
|
|
Schmuli wrote: long function or variable names
Ummm... how long? I use fully-specified names, but I split them at the dots when needed.
Schmuli wrote: I also don't like breaking up strings onto separate lines
Neither do I.
Schmuli wrote: as that requires additional concatenation, which is wasteful
That happens at compile time doesn't it?
|
|
|
|
|
Generally speaking, long names don't always make a problem, but it does crop up now and then. I don't like to split an operation, so I wont split at the dots either. I would much rather have a long line that clearly displays the operation being performed, than break it up onto a number of lines. Again, in such a case, I will attempt to use the most atomic operations possible, to help keep the lines as short as possible.
When breaking a string up, for example in C#, you need to end the string on each line, and add a '+' for each following line. This is runtime concatenation. I do believe there are other compilers (VB?) that will perform the concatenation at compile time, so that would depend on the compiler, I guess.
|
|
|
|
|
In Eclipse, I hit the reformat command all the time. Whatever the settings are, that's what happens. (I do tinker with the settings at first, but once done I just let it do its thing.)
This makes the comments go all wonky sometimes, but that's not too important.
Visual Studio has really, really sucky reformatting. Pisses me right off, it does.
Recently started using NetBeans, and it's somewhere between Eclipse and VS.
If I'm using TextPad, then I use line breaks depending on my mood. I hate horizontal scrolling, but if all I have is text (such as a print statement), I may keep it on a single line to avoid wasting too much vertical space.
Basically, I format using the 1TBS.
Don't let my name fool you. That's my job.
|
|
|
|
|
I don't know about Eclipse, but in Visual Studio, once you break an operation onto multiple lines, formatting will not make any changes to the number of lines, nor will it decide if a line is too long and break it up.
I use Visual Studio all the time, and I have never had a problem with the formatting. Then again, I started programming in VS, so I guess my formatting preferences are based on what is available in VS.
|
|
|
|
|
I started programming a little bit before Visual Studio, but not too far: it was in the Trash 80 command line. Forget punch cards, some of the older guys literally had to wire their own boards to make a program.
The refusal to un-break lines is minor compared to the forcing of a bad bracing style.
Not being a total dick, I define "bad" here to mean "one that I don't want to use", rather than one that is actually bad. Eclipse has a default, but allows you to customize that to whatever you want.
I developed my own personal style before I ever got on the Internet, and I was surprised to discover that it very closely aligned with the 1TBS.
Would it kill MS to give people more flexibility? Sheesh.
Don't let my name fool you. That's my job.
|
|
|
|
|
From your choice of wording, I'm going to assume you are not aware that VS allows you to customize the formatting as well? This can be done on a per-language basis, using the Tool -> Options... -> Text Editor -> [Language] -> Formatting.
I wasn't actually aware that there were names given for different styles of formatting, such 1TBS, so I went to wikipedia[^] to find out more (you learn something new everyday, huh?). Apparently, my style is actually mostly my own: I use the Allman style mostly, but have a few things I do differently, although I'm not sure where I got them from.
|
|
|
|
|
but when I checked it I realized I had seen it already. It's nothing close to enough.
I'm guessing you've never seen Eclipse' formatting options. It's primarily a Java IDE, but it's free, so you should take a look if you get a chance.
THAT is how code editors should be. At least for formatting options.
There are things I cannot do well (or at all) in it that I can do in VS, or more often better in TextPad. But on the whole, it is very tunable for the programmer's taste.
Sun's NetBeans IDE is a bit more like VS in that they want to prescribe what you have to use, but let you have a tiny amount of control.
Don't let my name fool you. That's my job.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
