Path: utzoo!attcan!uunet!lll-winken!ames!mailrus!tut.cis.ohio-state.edu!ukma!xanth!nic.MR.NET!umn-d-ub!umn-cs!ns!ddb From: ddb@ns.UUCP (David Dyer-Bennet) Newsgroups: comp.lang.c Subject: Re: Proposal for a scientific look at C style choices Message-ID: <1068@ns.UUCP> Date: 13 Jan 89 22:41:14 GMT References: <132@mole-end.UUCP> <1045@ns.UUCP> <1066@ns.UUCP> <11091@ulysses.homer.nj.att.com> Reply-To: ddb@ns.UUCP (David Dyer-Bennet) Organization: Terrabit Software Lines: 76 In article <11091@ulysses.homer.nj.att.com> ggs@ulysses.homer.nj.att.com (Griff Smith) writes: :I'm using this as an excuse to suggest a theory: two kinds of people :are arguing, and they have different perceptual strengths. : :David Dyer-Bennet seems to be a member of the `parsing' school. These :people like to `read' code instead of `seeing' it. I won't explain :their perceptions, because I can't empathise with them. I think this analysis is right -- except I think I'm in the visual camp; I'm the one who was explaining my use of whitespace and placement in terms of page design, and in terms of finding things visually. :They make life miserable for me, however. Er, sorry about that. :When they format similar code, it's something like : :if (whatever && something_else && : something_on_the_next_line && : something_short && something_longer && : the_end_of_the_list) { : mumble; :} In my case, this would be: if (whatever && something_else && something on the next line && and_so_forth_on_and_on_until && the_end_of_the_list) { the_body; of_the; compound_statement; } And I consider this suboptimally readable. I don't encounter long continued booleans in the if that often. If I did, I might revise my style at least for those particular statements, because I agree with you that there's some difficulty separating the conditional from the body in the above. Do you have trouble with the simpler case of if (simple one-line conditional) { body_of; compound_statement; } ? Essentially, I tend to think of "continuation lines" (like the long conditional in your example) as exception cases, rather than the norm, so my style handles them less cleanly than what I think of as the common cases. :This style maximizes my confusion by forcing me to `find' all the :component markers instead of `seeing' them. I have lost most of the :visual cues, and I have to go wading through the code with my defective :parser. I suspect the `parsers' are equally disturbed by having to :discard my superfluous white-space. As I format it, the indentation depth provides the visual cue still. I hope. I don't parse code well either. This is easily determined by presenting me with code formatted in ways contrary to the actual meaning, and see how long it takes me to find it! :I don't have any solutions. I do wish the two sides would be more :sympathetic to each other's problems. I'm learning a lot from this dialogue, and I'm really pleased it IS a dialogue rather than a shouting match. As you say, we aren't likely to all come to a common solution, but building understanding of the problem is valuable. -- -- David Dyer-Bennet ...!{rutgers!dayton | amdahl!ems | uunet!rosevax}!umn-cs!ns!ddb ddb@Lynx.MN.Org, ...{amdahl,hpda}!bungia!viper!ddb Fidonet 1:282/341.0, (612) 721-8967 hst/2400/1200/300