|
osdir.com mailing list archive |
|
Subject: indented code - msg#00008List: linux.redhat.blinux.develDidn'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) { stuff; } 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. int foo(int x, int y) { function stuff; } /* foo */ Indent can be told to format in precisely this way. The following .indent.pro 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! -nsob -ncdb -nbad -nbap -nbbb // Measure levels of indenting - I prefer 4 spaces, rather than 2. // But 8 would force the tab indenting. -i4 -bli4 -cbi4 -lp -ci0 -pi0 -cli0 -di2 // Braces are set by the coding standards of the linux kernel -br -brs -cdw -ce -nbs // Breaking long lines? -l80 -hnl -psl -nbbo // Inserting spaces - usually I don't want it -nprs -npcs -ncs -nsaf -nsai -nsaw -ss Any thoughts on these settings, from a blind or sighted perspective? Karl Dahlke Thread at a glance:
Previous Message by Date: click to view message previewRe: edbrowseOn Wed, Feb 15, 2006 at 06:31:08PM -0800, T. Joseph CARTER wrote: > Samuel, Karl pointed out in an offlist reply the obvious--that indentation > doesn't matter or help a totally blind person much. (I'd argue it does if > they have a Braille display, but these things are expensive as we all > know far too well..) They are expensive but that's beside the point. Quite a few people have braille displays, especially in Europe where, apparently, some governments offer subsedies or even meet the entire cost. Indentation is helpful when reading code with a braille display, as it is if one has speech software that announces the indentation level at the start of each line. Emacspeak is a superb example. I think a braille display is ideal for programming. In writing shell scripts and reading code for various other purposes I've found it much more convenient to work in braille - yes, I'm one of the lucky ones who found funding with which to purchase a braille display, in a country where state subsedies for such equipment aren't offered. My advice: indent your code properly if you want others to read it, and disability has nothing to do with it. Next Message by Date: click to view message previewRe: indented codeKarl Dahlke wrote: > Well - I seem to have inadvertantly started a fire storm. > Didn't mean to do that. I'm just happy to see that this list is alive. the users list is for users who mostly don't care about code details. [.. Snip stuff about jumping to matching braces ..] > Now that I'm use to this feature, I don't know what I'd do without it. It sure is handy, especially for code where the opening brace doesn't begin a newline. In my own code, I start a new line for a new brace, but I try to match the style of the code I'm working on where possible. [.. Snip stuff on using indent ..] There's some option to indent that causes it to indent foo and *bar differently because *bar has the * on it. This option is annoying, and I never did figure out whether that can be seperately controlled from the option that seperates types from identifiers in variable declarations. My advice: have indent just have one space as in int foo; rather than try to do the visual alignment thing in that case. It just comes out ugly. GNU indent allows you to specify -ts 4 if you prefer 4 space indent with hard tabs. I have vim set up this way by default, but have actually set up a macro to cycle between that an a couple of other typical settings people use. Once again, I code my way, but for other people's projects I try to code their way. Linus Torvalds is widely quoted recommending that you print a copy of the GNU Coding Standards, and then burn them as a symbolic gesture. This isn't a bad idea. The one formatting thing I never understood about GNU is that they want a newline and a two-space indent for an opening brace, then another newline and two-space indent for the content of the block. I start a new line for an opening brace to keep blocks' opening and closing points easily visible. Contents of blocks I indent sure, but not the opening and closing braces. That's just strange. -- "We are what we repeatedly do. Excellence, therefore, is not an act, but a habit." -- Aristotle Previous Message by Thread: click to view message previewLike to contributeHiI am a project trainee at IBM and wold like to contribute to the Blinux project but I am not sure how. I would love to develop something for my project at IBM.Could someone please point me in the right direction. Regards,Deepak _______________________________________________ Blinux-develop mailing list Blinux-develop@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/blinux-develop Next Message by Thread: click to view message previewRe: indented codeKarl Dahlke wrote: > Well - I seem to have inadvertantly started a fire storm. > Didn't mean to do that. I'm just happy to see that this list is alive. the users list is for users who mostly don't care about code details. [.. Snip stuff about jumping to matching braces ..] > Now that I'm use to this feature, I don't know what I'd do without it. It sure is handy, especially for code where the opening brace doesn't begin a newline. In my own code, I start a new line for a new brace, but I try to match the style of the code I'm working on where possible. [.. Snip stuff on using indent ..] There's some option to indent that causes it to indent foo and *bar differently because *bar has the * on it. This option is annoying, and I never did figure out whether that can be seperately controlled from the option that seperates types from identifiers in variable declarations. My advice: have indent just have one space as in int foo; rather than try to do the visual alignment thing in that case. It just comes out ugly. GNU indent allows you to specify -ts 4 if you prefer 4 space indent with hard tabs. I have vim set up this way by default, but have actually set up a macro to cycle between that an a couple of other typical settings people use. Once again, I code my way, but for other people's projects I try to code their way. Linus Torvalds is widely quoted recommending that you print a copy of the GNU Coding Standards, and then burn them as a symbolic gesture. This isn't a bad idea. The one formatting thing I never understood about GNU is that they want a newline and a two-space indent for an opening brace, then another newline and two-space indent for the content of the block. I start a new line for an opening brace to keep blocks' opening and closing points easily visible. Contents of blocks I indent sure, but not the opening and closing braces. That's just strange. -- "We are what we repeatedly do. Excellence, therefore, is not an act, but a habit." -- Aristotle Loading Comments...
|
|
