Style Sensitivity
Jackman
I wish to initiate this post by saying I do not wish to initiate a
flame war and I don't want to step on anyone's toes. Instead, I want
to solicit compromise. If you do not like what I have to say, it is
not requisite that you state your distaste. I will speak honestly,
however, while trying not to be offensive. Moreover, I apologize for
any incorrect word usage or poor grammar now. If you need
clarification, I will be happy to provide it. In short, I want to be
civil, I expect the same.
I have seen both in the mailing list archives and the IRC channel a
number of complaints regarding the requirement to have braces on the
same lines as function declarations. For example:
main() {
[insert code here]
}
In contrast, many traditional coding styles allow this kind of code:
main()
{
[code]
}
The complaints are that the latter code is simply not acceptable. As
far as I can tell, the rebuke is generally, "Tough. Get used to it."
This is belongs to a class of the most insulting responses I have ever
heard from anyone on any topic.
I will now and try to explain what I see has happened to make my point clearer.
It was the desire of the language designers to do away with line
terminators (;). So, they added some code to terminate all lines with
a semicolon unless the line ended with a brace ({). The desired
result was achieved, but required that all lines not needing a
semicolon needed a brace. This, in turn, forced something like a KNF
coding style (http://en.wikipedia.org/wiki/Indent_style#BSD_KNF_style),
outlawing anything like the K&R style (braces on separate lines).
This paragraph should be supported by
http://golang.org/doc/effective_go.html#semicolons unless I am
mistaken.
Instead of making additional changes to retain flexibility (like
checking for a brace on the next non-whitespace line), the opportunity
was taken to make coding style more strict. This appears to me to be
an example of a violation of the rules of Separation and Robustness
(http://catb.org/~esr/writings/taoup/html/). The code is no longer
flexible and error tolerant. When software should be flexible for
people, the people must be flexible for the software.
Now, I realize that this may seem silly, to argue over coding styles.
My point is not to argue over which coding style is best, or to say
which we should adopt. Instead, I want to promote flexibility and
tolerance. I want the compiler to accept a variety of coding styles,
not just my own. The real silliness comes when people discriminate
(without reason) and insult based on the way someone does something
when it really doesn't matter (like putting in whitespace or
newlines).
Don't get me wrong. I appreciate the idea of having a universal
coding style, which I will explain below. I just don't want to be
told how to think about writing and reading code.
When I hear people talk about how it /should/ be done, I somehow
recall scenes from Equilibrium, 1984, and Fahrenheit 451. "There is
only one way to do things and that's the most efficient way!" In *NIX
terms, "emacs is the best editor and we should only use emacs! Down
with vi!"
I want to illicit a compromise. I want braces on new lines. I'm not
the only one. As the current system stands, several formatting steps
must be taken for me to compile the code AND keep it in my coding
style and the coding style which is enforced by my work and by my
classes. The solution at work and at school has been to run the code
through a formatter (like gofmt) before we turn in the final source.
It has never been required in my experience to format the code before
compiling as long as proper tokens have been used. I propose
something similar to what is done in the workplace and in schools.
I suggest there be an OFFICIAL Go style. This style will be enforced
on public archives, tutorials, mailing lists, and so forth. To post
code in any other style will be VERY bad manners (as it already is),
and may result in refused code submissions. Like people who continue
to topmost despite moderator warnings, those who post poorly formatted
code should be shunned and shipped off to a penal colony. In other
words, the politics will be left in the political arena and kept out
of the technical one. With time and exposure to that singular
official style, no one will have to enforce the style. It'll just
happen.
I do not think this will difficult as I'm really impressed with gofmt.
gofmt permits people to change code styles quickly and easily from
the command line. The default behavior may stay as it is, in the case
I've proposed, but, with switches, it may also be used to reformat
code to other styles. This is not work that need be done by
maintainers, but by community contributions. I don't want maintainers
to feel pressured to work (but to relax).
The reason I am writing this proposal in this way is because it seems
this is a political change and not a technical one. This change has
not been the result of community contributions and mutual agreement,
but rather as a mandate. If it were as simple as submitting a code
change, I would do so or someone else would have done so already, I'm
sure.
Once again, I invite people to respond with rational arguments and
civil discussion as a favor to myself. I am making myself available
off-list for those who want to address me directly. More than
anything, I'd like the opportunity to speak with the person(s) who
established the code style policy -- please contact me if you're
listening as I don't know who you are.
Thank you for your time and thank you for Go. It's a wonderful language.
--
Andrew Jackman
kd7...@gmail.com
CONFIDENTIALITY NOTICE: This e-mail message, including any
attachments, is for the sole use of the intended recipient(s) and may
contain confidential and privileged information. Any unauthorized
review, use, disclosure, or distribution is prohibited. If you are not
the intended recipient, please contact the sender by reply e-mail and
destroy all copies of the original message. All your base are belong
to us.
befelemepeseveze
> The reason I am writing this proposal in this way is because it seems
> this is a political change and not a technical one.
IMHO it's somewhat both of it. The "political" part is a design choice
of having the language now almost semicolon free and this has (almost)
nothing in common with coding style. The technical part - in contrast
- can (I guess) be done allowing any style, but I assume, such goal is
pretty complex (or at least more complex) and probably also slower in
implementation then the adopted (presumably) faster and less complex
way, which does have (few) restrictions on the style. So I see this as
a (well thought) compromise and a reasonable one. Still I understand,
that it may not be the same for others. I'm not going to say "Get used
to it", but I doubt there is (would be) any other option.
Alex Combas
Best regards,
Alex Combas
Sonia Keys
...
> main() {
> [insert code here]
> }
In (current) Go, this is not a matter of style, it is simply the
language definition.
> ...supported by http://golang.org/doc/effective_go.html#semicolons
I would like to see this documentation changed. As far as the Go
programmer is concerned, lines are not terminated with semicolons.
That semicolons are inserted by the lexer is interesting, but I would
rather not have to think about what goes on behind the scene in the
compiler as I program. I would like to see the documentation explain
where line terminators are allowed, and have this explanation not
reference virtual semicolons.
Qtvali
same line, because it makes code shorter. Where there are 10
functions, each taking 2-line body, I have those lines additionally:
header line, closing bracket and one empty line. This makes 5. 50
lines per 10 functions. Otherwise it would be 6. If they take 50 lines
without loosing what last bracket on other line gives (way to do fast
cut-and-paste, delete or add lines) and what this empty line does -
separating - I don't see any good reason to have this line feed there.
It simply takes space without giving nothing. I like to have things on
my screen at once.
Vincent Foley
that begins that block, I feel the same way you do, because the new
semicolon rule broke all my code that used else. Instead of doing
this:
if something {
...
}
else {
...
}
Which is my preferred style, because the keywords are aligned, I now
need to write my code like this:
if something {
...
} else {
...
}
Which I don't like quite as much, but have now no choice, but to use
since the other way is now a syntax error.
Douglas Crockford of JavaScript fame commented in a Google Tech Talk
about how implicit semi-colons caused problems in JavaScript. I
would've rather that Go keeps semi-colons and avoid those problems.
Vincent.
On Dec 31, 2:16 am, Jackman <kd7...@gmail.com> wrote:
> This paragraph should be supported byhttp://golang.org/doc/effective_go.html#semicolonsunless I am
jimmy frasche
with brace or layout structure. But ultimately I don't really care.
If someone won't learn a language because of something as meaningless
as brace placement, I can't say anything about them that is not
denigrating.
That documentation does look like it needs to be cleaned up.
Vincent Risi
rational system.
main() {
x = ...
}
main()
{
x = ...
}
main()
{
x = ...
}
The first popularly known as k&r from the original white book. I think
forcing people to code k&r is basically bad form. Why not just write
one statement per line as in visual basic, with semicolons to write
more than one statement per line. Seeing as Go is not c why not use
the rules of awk where if you want to continue one statement on a new
line either us a backslash or end the line with a comma. At least
Basic and awk make it hard not to use but their simple conventions.
The next thing is the statement you must use tabs instead of spaces
for indentation. I personally dislike tabs as they cannot be seen as
tabs and look like spaces, which is equally as horrible as in the old
360 days when spaces and low-values where indistinguishable.
On Dec 31, 9:16 am, Jackman <kd7...@gmail.com> wrote:
> To whom it may concern:
> blah blah blah
emghazal
> In (current) Go, this is not a matter of style, it is simply the
> language definition.
I totally agree.
Don't think of it as a different style, think of as a different
language. Go is not C.
Another thing that Ian (I'm not 100% sure it was him) pointed out in
another thread is the parentheses around the if condition. When go was
released to the public, it didn't require them, and no one complained.
If go was first released with the current semicolon rules, no one
would've complained either.
Nigel
On Dec 31, 7:16 am, Jackman <kd7...@gmail.com> wrote:
>
> I have seen both in the mailing list archives and the IRC channel a
> number of complaints regarding the requirement to have braces on the
> same lines as function declarations. For example:
>
> main() {
> [insert code here]
>
> }
>
> In contrast, many traditional coding styles allow this kind of code:
>
> main()
> {
> [code]
>
> }
>
I am looking at Go from the point of writing Safety Critical
Software. An important part of developing Safety Critical Code is
manual code inspections and a common practice in this activity is to
Line Out the braces. To do this you need to have opening and closing
braces on a line of their own. My Master's dissertation was on the use
of C++ for Safety Critical Programming and it basically said don't use
it. Go effectively addresses nearly every issue I raised in that
thesis (some years ago) and looks like it would be an ideal candidate
for SCP once it gets a bit more stable. However, currently there is
no way I could recommend it for this use simply because of the brace
issue.
A bit of history might come in useful here. The practice of putting
the opening brace on the same line as a statement came about because
of the need make as much code as possible visible on screens that had
only a limited number of lines. The first monitor I worked with
programming in C only displayed 24 lines on the screen, so putting the
opening brace on the line of the statement it applied to saved space.
You could get more code on screen. Most coders I knew back then did
it, but we all accepted it was bad practice. Unfortunately we fell
into the habit of writing code in that style and as we were the early
C adopters ended up being the trend setters and others copied us
because they thought this was the way to write C code. By that time
screens could display a lot more and the need to use the style had
dispersed.
In 1994 I did an experiment in which I had a the same code manually
examined by different code examiners. There were two versions of the
code, one with aligned braces and the other with opening braces on the
same line as the statement. The code did contain flow logic errors.
Where the braces were aligned 98% of the examinations picked up the
error, however with non-aligned braces this dropped to 64%. For this
reason I would press for a change that will allow opening braces to be
placed on the following line.
Nigel Backhurst
Alex Combas
I think the change to no semicolons is bizarre and fragile--either go
with brace or layout structure. But ultimately I don't really care.
If someone won't learn a language because of something as meaningless
as brace placement, I can't say anything about them that is not
denigrating.
That documentation does look like it needs to be cleaned up.
jimmy frasche
> I am looking at Go from the point of writing Safety Critical
> Software. An important part of developing Safety Critical Code is
> manual code inspections and a common practice in this activity is to
> Line Out the braces. To do this you need to have opening and closing
> braces on a line of their own. My Master's dissertation was on the use
> of C++ for Safety Critical Programming and it basically said don't use
> it. Go effectively addresses nearly every issue I raised in that
> thesis (some years ago) and looks like it would be an ideal candidate
> for SCP once it gets a bit more stable. However, currently there is
> no way I could recommend it for this use simply because of the brace
> issue.
How would a language like Python or Haskel fit into this scheme? Why
do you line out the braces? What does it signify?
> In 1994 I did an experiment in which I had a the same code manually
> examined by different code examiners. There were two versions of the
> code, one with aligned braces and the other with opening braces on the
> same line as the statement. The code did contain flow logic errors.
> Where the braces were aligned 98% of the examinations picked up the
> error, however with non-aligned braces this dropped to 64%. For this
> reason I would press for a change that will allow opening braces to be
> placed on the following line.
You are going to have to provide more details of the experiment design
for me to even begin to believe this.
msw
This topic has already been beaten to death. They aren't interested in
compromise and it is their language. I don't speak for the designers
and they might put it more tactfully than did I.
Devon H. O'Dell
> http://golang.org/doc/effective_go.html#formatting
>
> This topic has already been beaten to death. They aren't interested in
> compromise and it is their language. I don't speak for the designers
> and they might put it more tactfully than did I.
No, that's not what has been said. What has been said is `use it for a
while and see.' If nobody likes it after using it, so be it. I was
(silently) skeptical of the change, but having used it, I like how it
works. YMMV, but give it an honest try first.
--dho
jimmy frasche
formatable source code itself. It is one of the ancient holy wars.
It's not going to end here or make any more sense than it does
elsewhere. Just sit back and enjoy the ridiculous arguments and the
sheer absurdity of the amount of energy spent on the topic.
Tom Abernathy
> main() {
> [insert code here]
>
> }
Reasons why this format is better.
1) Save a line so information is displayed more consisely and so
reader is less likely to lose context when scanning the file.
2) Allows the reader to scan for the termination of the function
based on the indentation level of the closing token matching the
indentation of function name.
> main()
> {
> [code]
>
> }
Problems with this format.
1) Extra line that imparts no extra information.
2) {} are now separated from the function. They seem to be floating in
the code as if some type of grouping operator.
Ben Tilly
[...]
> In 1994 I did an experiment in which I had a the same code manually
> examined by different code examiners. There were two versions of the
> code, one with aligned braces and the other with opening braces on the
> same line as the statement. The code did contain flow logic errors.
> Where the braces were aligned 98% of the examinations picked up the
> error, however with non-aligned braces this dropped to 64%. For this
> reason I would press for a change that will allow opening braces to be
> placed on the following line.
I would love to have more details on this experiment. Because if
there is a demonstrable difference in ease of auditing code based on
formatting style, I would change my own personal style in a heartbeat.
In particular I would like to see details on any possible causes of
the difference. For instance it is very easy for me to believe that
you'd get such a big jump in quality of inspections if the inspectors
were used to one formatting style and were faced with inspecting code
formatted with a different one. But if your inspectors did worse in
inspecting code formatted with a style they are used to writing, that
would be strong evidence for that style being objectively inferior.
Cheers,
Ben
Alex Combas
jimmy frasche
> The only thing that is absurd is saying that this is in any way like a holy
> war.
> There needs to be a "holy war" version of Godwin's law.
http://www.outpost9.com/reference/jargon/jargon_23.html#TAG897
There also needs to be a brace/whitespace version.
Jessta
formatting by creating a standard format seems to have actually lead
to more of a discussion of formatting. But I guess it's better that
the discussion is here in the language mailing list, instead of in the
mailing list of every project that ever uses go for decades to come.
The semicolon change has resulted in the enforcement of the bracing
style that was already the standard in gofmt.
If you gofmt your code, then it will compile. Which to me seems
perfectly reasonable for the small minority that will be avoiding the
standard style. Just add gofmt'ing to your make file and forget about
it.
Myself, I've been having great trouble adapting to not putting ()
around my if,for statements, and I'm always putting semicolons at the
end of everything and forgetting the order of name and type in
variable declarations, but I believe given a few months of coding I'll
be used to it.
Since 99% of go code will be in the standard style is seems silly to
add extra hacks to the compiler parser just to accommodate a minority
of code. There are plenty of much more important things for the
developers and the community to worry about(generics,optimisations,
new GC, more library support etc.).
ps. I'd like the bike shed to be purple with pink poker dots because
it brings out my eyes.
- jessta
--
=====================
http://jessta.id.au
Nigel Backhufrst - I-E-A
The experiment was actually set up to assess the effectiveness of two
different approaches to teaching Code Inspection standards for a SCP
environment. At the time the company I was working for was supplying
courses in two forms, either a two day taught seminar, or a computer
based package that the user worked through with a work book. The courses
were being provided to a number different organisations who had
development groups in various EU countries. Each person coming onto one
of the courses, either computer based or seminar was first required to
do a sample code inspection on a piece of code. Then, three months
after they had completed the course they were asked to do a code
inspection on a different piece of code, which had the same type of
errors in it. We used an automatic code formatting tool to format the
code in accordance with the coding standards of the organisation that
the people were working in. It was just by chance that one used aligned
braces and one did not, we were not looking at that as an issue, which
is a major weakness in the experiment. If we had been I think we would
have designed it somewhat differently.
One of the errors in the code was an incorrect placement of the closing
brace on a loop function. It had been placed so that a function call
that should have been executed after the loop had been completed was
actually executed on each interation of the loop. The effect of this
did not stop the programe from functioning but did slow the execution
time. This is the type of code error that can only be picked up by
manual code inspection.
I do not have the exact numbers to hand as the company ceased trading
some eight years ago and the records no longer exist so far as I am
aware. So far as I can recall just under three hundred people went
through the code inspection course on a roughly fifty fifty split
between those attending seminars and those doing the online course. We
found that the form of presentation actually made very little difference
to things. The braces result was not something we were looking at or
particular interested in at the time of the experiment. It was just
something that came out of the analysis. It was only when we went back
to try to identify why the one group did so badly on picking up this
error that it was realised that due to the non-alignment of braces, they
had been unable to apply one of the techniques that was taught as part
of the course, i.e. taking the hard copy of the code and physically
drawing coloured lines between braces to show where the blocks are.
A couple of years after this when I was doing my Master's dissertation
on Safety Critical Programming I wanted to look into this again but was
not able to obtain funding to set up a good study of the issue.
One thing that I think needs to kept in mind is that I think it makes a
difference on whether the code has been printed out as hard copy or is
being viewed on a screen. However, I have no evidence for this and as
far as I am aware there has been no work done on this. Might suggest it
to a friend of mine who is a Psychology post grad as a subject that may
be worth looking into. Is there a difference in the way we perceive code
according to the medium on which we are looking at it? It may be that we
have to look at formatting code differently for different types of
presentation.
Regards
Nigel
--
Nigel Backhurst MSc BA(Hons) FFA
Information Engineering Associates
14 Deacon Street
Leicester LE2 7EF
msw
Unfortunately, post hoc data analysis is rightly avoided in such
experiments as (using standard significance tests) 1 out of 20
correlations found by such methods will be completely spurious. These
retrospective tests are often derisively called "shotgun analysis"
because they are almost guaranteed to yield some result when the issue
under test fails to generate the anticipated result: given enough
variables, the shotgun will hit something.
This does not imply that the effect doesn't exist, but neither does it
provide compelling support that it does. Such results can only inform
that a follow-on study explicitly testing new found correlation be
conducted.
(I say this having fruitlessly hunted the snark in a research program
conducted in my undergraduate days only to learn that my endeavors
were folly from the start.)
Ben Tilly
Interesting.
First of all given the numbers you have reported, we can discount
chance. Even if you have substantially misremembered them, we can
discount chance. If you split 250 people evenly, and the success
rates are 64 and 98, you can't apply a chi-square test because because
you don't have enough failures. But any reasonably valid procedure
will get a p-value of effectively 0. Even if you misremember the
numbers and the actual success rates were 74% and 88%, you'd still be
at p < 0.01, which is fine for a 99% confidence interval.
However there are two possible explanations that remain.
The first is simply that different organizations attract people of
different quality. This effect has shown up elsewhere in the
literature. For instance Peopleware cites a set of "coding war games"
that they did. They found 10 to 1 productivity differences between
different programmers. But the strongest result that they got is that
the best predictor of how good a particular programmer is is how good
other programmers from the same organization are. Thus consistent
variations in quality between programmers from different organizations
are an expected result.
The second is that when presented with a mismatch between training and
formatting style that a significant number of people forgot the
possibility of the test rather than adapting it to the different code
style. The likely reason being that memory tends to be cued - if you
don't see the visual pattern which you were taught to look for, you
are less likely to remember that there is a test that can be done
using that pattern. Therefore you are really measuring the
effectiveness of doing that procedure versus not doing that procedure.
In principle nothing stops anyone from drawing vertical lines from the
line of code that opens a block to the one that finishes it. That
logically should be equivalent to the procedure that was taught. The
question then becomes how likely people who went through training in
doing that are to remember and apply the pattern over time.
> A couple of years after this when I was doing my Master's dissertation on
> Safety Critical Programming I wanted to look into this again but was not
> able to obtain funding to set up a good study of the issue.
Too bad. I would love to see this replicated in a better environment.
> One thing that I think needs to kept in mind is that I think it makes a
> difference on whether the code has been printed out as hard copy or is being
> viewed on a screen. However, I have no evidence for this and as far as I am
> aware there has been no work done on this. Might suggest it to a friend of
> mine who is a Psychology post grad as a subject that may be worth looking
> into. Is there a difference in the way we perceive code according to the
> medium on which we are looking at it? It may be that we have to look at
> formatting code differently for different types of presentation.
If people have been trained to read code by marking it up, drawing
lines, etc, then the medium could make a difference. In the absence
of that factor I have trouble seeing it make a difference.
Cheers,
Ben
Michael Campbell
> On Fri, Jan 1, 2010 at 12:26 AM, Nigel Backhufrst - I-E-A
> <ni...@i-e-a.eu> wrote:
>
>> Hi Ben
>>
>> On 31/12/2009 23:48, Ben Tilly wrote:
>>
>>> On 12/31/09, Nigel<ni...@i-e-a.eu> wrote:
>>> [...]
>>>
>>>
>>>> In 1994 I did an experiment in which I had a the same code manually
>>>> examined by different code examiners. There were two versions of the
>>>> code, one with aligned braces and the other with opening braces on the
>>>> same line as the statement. The code did contain flow logic errors.
>>>> Where the braces were aligned 98% of the examinations picked up the
>>>> error, however with non-aligned braces this dropped to 64%. For this
>>>> reason I would press for a change that will allow opening braces to be
>>>> placed on the following line.
I'm late to the party here, but was the use of an auto-formatter
considered in this experiment? I'll admit to not having used Go yet to
any meaningful degree, but "where braces are" stopped being even a
miniscule issue for me when IDE's started being able to format the code
based on them, and I was doing this in emacs years before any dedicated
GUI IDE's were even a twinkle in my eye.
The shape of the code is an instant giveaway to logical flow (or is for
me, using C-based imperative languages), so these formatters are crucial
in my day-to-day. It's like the Smug Lisp Weenies always say; after a
time, they don't even SEE the parenthesis.
Jeffrey
> In principle nothing stops anyone from drawing vertical lines from the
> line of code that opens a block to the one that finishes it. That
> logically should be equivalent to the procedure that was taught. The
> question then becomes how likely people who went through training in
> doing that are to remember and apply the pattern over time.
I remember twenty years ago going through a code inspections class
where we were taught to read code by marking it up. It was for a
proprietary OS, and the language used BEGIN and END to mark blocks.
There was no uniform style for the placement of BEGIN and END, but yet
I never found it difficult to use one pen to match the BEGIN and END,
and another colored pen to then put a line on the left side showing
the extent of the block. No one I knew had difficulties with that
either.
>> One thing that I think needs to kept in mind is that I think it makes a
>> difference on whether the code has been printed out as hard copy or is being
>> viewed on a screen. [...snip...]
>>
> If people have been trained to read code by marking it up, drawing
> lines, etc, then the medium could make a difference. In the absence
> of that factor I have trouble seeing it make a difference.
As someone who now does code inspections almost entirely on screen
(whether the review is being done just by myself in my cube, or
whether the code is being projected onto a screen in a conference
room), I think the medium does make a difference. With modern tools,
you can just use the editor or source code difference formatter to
show the matching braces. You put your cursor on one brace, and the
other brace is highlighted, and you can jump to that brace if you
want. I've used vimdiff for a long time, but I'm sure there others
that work fine if not better.
The one disadvantage that a screen has is that you cannot lay an
arbitrary number of screens side by side in order to see a long loop
in its entirety. With paper, you could just spread the sheets across
your desk. As a consequence, it's seems like it is important to code
in a way where you can see as much code as possible on a screen.
(Even to this day, if the loop is long, I can't inspect it on the
screen but resort to printing it out.)
Here is the main advantage that putting an opening brace on the same
line as the control construct: it conserves vertical space, which is
important in the modern environment where code is reviewed generally
by displaying and less frequently by printing it out. We should just
leave finding the matching braces to tools, which are less likely to
make mistakes.
- Jeffrey
emghazal
wrote:
> I'm late to the party here, but was the use of an auto-formatter
> considered in this experiment? I'll admit to not having used Go yet to
> any meaningful degree, but "where braces are" stopped being even a
> miniscule issue for me when IDE's started being able to format the code
> based on them, and I was doing this in emacs years before any dedicated
> GUI IDE's were even a twinkle in my eye.
>
Nigel Backhufrst-I-E-A already answered that:
"We used an automatic code formatting tool to format the
code in accordance with the coding standards of the organisation that
the people were working in."
In Go, an auto-formatter is a part of the toolchain, it's called
"gofmt". see:
http://golang.org/cmd/gofmt/
On Jan 2, 3:20 am, Jeffrey <merrick...@gmail.com> wrote:
> The one disadvantage that a screen has is that you cannot lay an
> arbitrary number of screens side by side in order to see a long loop
> in its entirety.
Some people can: http://www.biscade.com/office/
But yes, most people can't. I find IDE's that support code folding
quite useful for that.
Bob Cunningham
> The one disadvantage that a screen has is that you cannot lay an
> arbitrary number of screens side by side in order to see a long loop
> in its entirety. With paper, you could just spread the sheets across
> your desk. As a consequence, it's seems like it is important to code
> in a way where you can see as much code as possible on a screen.
> (Even to this day, if the loop is long, I can't inspect it on the
> screen but resort to printing it out.)
>
> Here is the main advantage that putting an opening brace on the same
> line as the control construct: it conserves vertical space, which is
> important in the modern environment where code is reviewed generally
> by displaying and less frequently by printing it out. We should just
> leave finding the matching braces to tools, which are less likely to
> make mistakes.
>
>
more and larger high-res monitors. I'm gunning for a set of 3 Samsung
2560x1600 30" Monitors. Yeah, baby!)
Jessta
>
> (Hey, cool it: I'm using the "vertical space" argument to justify buying
> more and larger high-res monitors. I'm gunning for a set of 3 Samsung
> 2560x1600 30" Monitors. Yeah, baby!)
>
>
Java programmer?
Bob Cunningham
> 2010/1/2 Bob Cunningham<Fly...@gmail.com>:
>
>> (Hey, cool it: I'm using the "vertical space" argument to justify buying
>> more and larger high-res monitors. I'm gunning for a set of 3 Samsung
>> 2560x1600 30" Monitors. Yeah, baby!)
>>
> Java programmer?
>
>
-BobC
roger peppe
> (Hey, cool it: I'm using the "vertical space" argument to justify buying
> more and larger high-res monitors. I'm gunning for a set of 3 Samsung
> 2560x1600 30" Monitors. Yeah, baby!)
i find that a 24" 1920x1200 monitor works really well rotated into portrait
mode. loads of vertical space, and enough horizontal space to have
two columns in acme.