indented code

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


Well - I seem to have inadvertantly started a fire storm.
Didn't mean to do that.
Let me mention a couple of things, and then I'll (mostly) give you the last word.

I have been writing software professionally for 25 years,
and personally, I have no use for indentation.
Nor would I want my adapter to speak the indent level of each line;
that would really slow me down.
I do put a comment on each right brace, describing the block
or function that is being closed off.
I suppose it's a verbal type of indent.
I also have the B command in edbrowse, for balancing braces,
to go to the "other" brace.
Now that I'm use to this feature, I don't know what I'd do without it.

On the other hand, it's clear to me how indenting helps the sighted community.
I can't deny it.
(I could see a long time ago.)
So a compromise is called for.

After some investigation I believe code can be automatically
indented in a way that does not hinder the blind, and is still acceptable
to the sighted.
By "acceptable" I'm using the coding standards set forth in the linux kernel.
I don't want to waste extra lines on braces, and neither does Linus.
So you indent like this

if(x) {
} else {
    more stuff;

Similar formatting applies for struct/enum definitions.
The function is the only time we invest an entire line in a single open brace.

foo(int x, int y)
    function stuff;
}  /* foo */

Indent can be told to format in precisely this way.
The following file seems to do a pretty good job for all parties,
and I will probably apply it to my edbrowse code in the next few days.

// leave blanklines alone!
// Measure levels of indenting - I prefer 4 spaces, rather than 2.
// But 8 would force the tab indenting.
// Braces are set by the coding standards of the linux kernel
// Breaking long lines?
// Inserting spaces - usually I don't want it

Any thoughts on these settings, from a blind or sighted perspective?

Karl Dahlke

[Index of Archives]     [Linux for the Blind]     [Fedora]     [Kernel List]     [Red Hat Install]     [Red Hat Watch List]     [Red Hat Development]     [Gimp]     [Yosemite News]     [Big List of Linux Books]