Stylistic questions on UNIX C coding.
in [Unix Programming]
|
Prev: integer
Next: shared memory question
From: Kelsey Bjarnason on 27 Feb 2010 18:23 On Sat, 27 Feb 2010 08:38:08 -0800, Nick Keighley wrote: > On 27 Feb, 05:32, Kelsey Bjarnason <kbjarna...(a)gmail.com> wrote: >> On Fri, 26 Feb 2010 12:29:13 +0000, Tim Streater wrote: > >> > Trouble with tabs is, what is a tab? >> >> It's a character, often ASCII 9, which tells your editor to indent (or, >> on removal, unindent) by whatever number of columns is required to >> bring things in line with the next (previous) tab stop. > > so your layout is tab-stop dependent And variable, to the individual coder's tastes, simply by their choice of tab stops, without messing it up for everyone else. Yes, indeed, tab- stop dependent, not "whatever number of spaces I think should be inserted here" dependent. >> Contrast that to hitting delete on a line which uses spaces instead of >> tabs. All this does is mess up the formatting, as the editor is almost >> certain to treat a space as a _space_, as it should, not as a tab, >> which it _shouldn't_, because the character involved is not a tab, but >> a space. > > get a better editor I have a better editor. One that understands the difference between spaces and tabs. One that does *not* do something as brain-dead as deleting _multiple_ characters when I press delete once. Any editor which deletes multiple items on a single delete simply cannot be trusted, it's liable to destroy something. >> Then, of course, there's inserting. Hit space. See how many columns >> the line indents. One, isn't it? > > but if I hit 'tab' No, sorry, we're using spaces here, not tabs. If you want to insert tabs, then by all means, use tabs. But then you're on my side of the fence, with spaces being defective by design for indent. If they weren't defective by design, you wouldn't be using tab instead of space. >> Why is that? Oh, yes, because spaces >> aren't tabs, and editors won't treat them as tabs. Tabs are tabs, and >> editors treat them that way. > > mine doesn't Then you should get an editor that works. >> or, when you >> hit the spacebar, correctly figures out that you actually meant a tab, >> not a space, and thus inserts 4 (or is it 3? 8? 5?) spaces. > > but TAB does that for me Exactly. Tab. Not space. If your editor - and the notion of spaces for indentation - weren't defective by design, you wouldn't need to use a special key to insert spaces; that's why you have a space bar. The fact you have to resort to something entirely different, the tab key, is prima facie evidence the whole notion of spaces to indent is as defective as it appears. Now, if your editor worked properly, using tabs instead of spaces, with the tab key inserting tabs as it should, then when viewed on someone else's display, rather than yours, it would show the code as *they* prefer to view it, rather than as *you* have decided is the only true way which everyone should be forced to view it in. Really, isn't this just a case of imposing your own layout conventions on others, rather than using a common sense approach which actually lets everyone view the code in their own preferred manner? Without having to defeat the needless additional complication of converting some godawful arrangement you happen to like into something actually manageable?
From: Ben Finney on 27 Feb 2010 19:08 Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups(a)NTLWorld.COM> writes: > > Set tabstop to 2, 3, 4, 5, 8, 179, whatever looks best to your > > preferences. > > > tabs 1,+1,+2,+3,+5,+8,+13,+21,+34,+55,+89 You're just telling fibs again. <snare roll> -- \ “Programs must be written for people to read, and only | `\ incidentally for machines to execute.” —Abelson & Sussman, | _o__) _Structure and Interpretation of Computer Programs_ | Ben Finney
From: Ike Naar on 27 Feb 2010 19:20 In article <4b8924a6$0$22939$e4fe514c(a)news.xs4all.nl>, Casper H.S. Dik <Casper.Dik(a)Sun.COM> wrote: >ike(a)localhost.claranet.nl (Ike Naar) writes: >> if (sscanf(input_buffer, "%d %d %d", &length, &width, &height) == 3 && >> sscanf(other_buffer, "%d %d %d", &color, &price, &weight) == 3 && >> needs_processing(color)) { >> compute_volume(length, width, height); >> compute_something_else(price, weight); >> } > >>vs. > >> if (sscanf(input_buffer, "%d %d %d", &length, &width, &height) == 3 && >> sscanf(other_buffer, "%d %d %d", &color, &price, &weight) == 3 && >> needs_processing(color)) >> { >> compute_volume(length, width, height); >> compute_something_else(price, weight); >> } > >>In the first case, it is hard to see where the condition ends >>and where the body starts. In the second case it's obvious. >>Don't you think that the opening brace on its own line here improves >>the readability? > >I call a strawman; a proper c-style will not allow the first form; >e.g., at Sun our style requires this form: > > if (sscanf(input_buffer, "%d %d %d", &length, &width, &height) == 3 && > sscanf(other_buffer, "%d %d %d", &color, &price, &weight) == 3 && > needs_processing(color)) { > compute_volume(length, width, height); > compute_something_else(price, weight); > } I don't think your strawman call is justified. My "first case" is the output of (gnu) "indent -kr".
From: Jonathan de Boyne Pollard on 27 Feb 2010 21:43 > > > Cost of a line feed is the same as the cost of a space character > That is only the case when one's terminal is set to NL0 mode and isn't set to ONLCR or ONLRET modes, or it is set to both CR0 and NL0 modes.
From: Nick Keighley on 1 Mar 2010 04:06
we may be talking at cross purposes as well as disagreeing. We also may be starting to repeat ourselves. Editors and code layouts are very personnel things. On 27 Feb, 23:23, Kelsey Bjarnason <kbjarna...(a)gmail.com> wrote: > On Sat, 27 Feb 2010 08:38:08 -0800, NickKeighleywrote: > > On 27 Feb, 05:32, Kelsey Bjarnason <kbjarna...(a)gmail.com> wrote: > >> On Fri, 26 Feb 2010 12:29:13 +0000, Tim Streater wrote: > >> > Trouble with tabs is, what is a tab? > > >> It's a character, often ASCII 9, which tells your editor to indent (or, > >> on removal, unindent) by whatever number of columns is required to > >> bring things in line with the next (previous) tab stop. ok. A <tab> character is ASCII 9 if found in source text (I know the world isn't ASCII, but a bit of concreteness here makes life a little easier). A <tab> is also a key on many keyboards. I'll try and distinguish <tab-char> from <tab-key>. > > so your layout is tab-stop dependent that is there are <tab-chars> in your source text. > And variable, to the individual coder's tastes, simply by their choice of > tab stops, without messing it up for everyone else. Yes, indeed, tab- > stop dependent, not "whatever number of spaces I think should be inserted > here" dependent. one difficulty with embedded <tab-chars> as the only layout character is that you lose fine control. void pippo (int n) { if ((n == PHOTON) || (n == LEPTON) || (n == HADRON)) { send_msg ("claim nobel!"); } } I don't see how this layout can survive spaceless layout or variable tab stops. Presumably you don't require layout like this. > >> Contrast that to hitting delete on a line which uses spaces instead of > >> tabs. All this does is mess up the formatting, as the editor is almost > >> certain to treat a space as a _space_, as it should, not as a tab, > >> which it _shouldn't_, because the character involved is not a tab, but > >> a space. > > > get a better editor > > I have a better editor. :-) > One that understands the difference between > spaces and tabs. One that does *not* do something as brain-dead as > deleting _multiple_ characters when I press delete once. Any editor > which deletes multiple items on a single delete simply cannot be trusted, > it's liable to destroy something. no. My editor (this is actually a configurable option) only does this for spaces. I assure you it works well in practice. > >> Then, of course, there's inserting. Hit space. See how many columns > >> the line indents. One, isn't it? > > > but if I hit 'tab' If I hit the <tab-key> it inserts N spaces. I still use the <tab-key> to indicate layout but the editor puts <spaces> in the source text. > No, sorry, we're using spaces here, not tabs. If you want to insert > tabs, then by all means, use tabs. If I want to insert <tab-chars> (eg. for the dreaded make file) I have to change an option on my editor. Normally I do not want to insert <tab-chars> > But then you're on my side of the > fence, with spaces being defective by design for indent. this is phrasing it rather strongly. There are plenty of people who have a different opinion from you. > If they weren't > defective by design, you wouldn't be using tab instead of space. is that <tab-char> or <tab-key>? <snip> [it's getting repetitive] > If your editor - and the notion of spaces for indentation - weren't > defective by design, you wouldn't need to use a special key to insert > spaces; that's why you have a space bar. The fact you have to resort to > something entirely different, the tab key, is prima facie evidence the > whole notion of spaces to indent is as defective as it appears. this is opinion masquerading as fact. I use the <tab-key> to indicate my layout requirement; the editor "compiles" this into <space> characters. A one-to-one mapping of key to text is not a requirement (plainly not or delete and backspace would always work the way I wanted them to on Unix!). > Now, if your editor worked properly, using tabs instead of spaces, with > the tab key inserting tabs as it should, then when viewed on someone > else's display, rather than yours, it would show the code as *they* > prefer to view it, rather than as *you* have decided is the only true way > which everyone should be forced to view it in. I like finer control over my layout than you do apparently > Really, isn't this just a case of imposing your own layout conventions on > others, rather than using a common sense approach which actually lets > everyone view the code in their own preferred manner? Without having to > defeat the needless additional complication of converting some godawful > arrangement you happen to like into something actually manageable? but you also require others to agree to your conventions. I bet you'd hate this approach Code laid out like this with 4 character indent xxxx yyyy zzzz wwww and using S and T to represent the "layout charcaters" actually looked like this xxxx SSSSyyyy Tzzzz TSSSSwwww the worst or all possible worlds! |