On Fri, May 22, 2015 at 05:39:22PM -0500, Bruce Dubbs wrote: > Ken Moffat wrote: > > > >For C-style code, 8 helps show the structure of a long function much > >better IMHO. > > That's your opinion. Actual research, including my own formal research, > shows differently. Would you like to read my dissertation? The title is > "The Effect of Comment and Code Style on Software Maintenance." > > I didn't think so. > Online searching only finds it in Texas, Doctor, so it probably doesn't accord with EU standards such as page size.
In the kernel, using a tab length of 8 helps to provide an indication that maybe you should refactor the code because the line lengths are becoming excessive. But then, kernel coders do not normally use a dictionary to help determine function names so perhaps the context is very different. For some other projects, with long names, an indentation of 8 is unwieldy. In any case, IFF a program works correctly, my experience suggests that the biggest maintenance burden is changing user requirements or a changing environment (I used to support payroll, very much subject to statutory changes). And almost any idiot coder can make a program hard to understand if you piss them off enough. Personally, I still adhere to what I learned in my DP work: "The great thing about standards is that we have are so many of them." In other words, pick and choose - particularly appropriate if you are doing something for pleasure, which is why we are here, but not appropriate for certain areas such as the military or tick-box employers, or safety-critical systems. But I do not code for those. > > I was actually referring to C code. Have you ever seen code with indents 10 > levels deep. I have and it was horrible. Changing to a smaller indent > improved things a little and was needed to just understand the code enough > to rewrite it. > I'm not sure if I've seen code with 10 levels of indentation, and I agree that reducing it would be a necessary first step on the way to a total rewrite. But on most terminals, 10 levels of indentation would be impractical with a tab length of 8. Maybe you got (un)lucky with long-lines in your terms. But I haven't done much in C, apart from trying to convert external 2.4 kernel code to 2.6 (the dreaded AmigaOne) and not getting a good enough result (flawed hardware, no cache coherency, and mine eventually overheated). For heavily indented code, manipulating a copy to reduce the indentation is obviously a first step. Then you use the test cases (you have them, right?), or create them, and then run them on both the old and the new code to identify regressions. ĸen - not formally qualified in what used to be called Data Processing, apart from a somewhat worthless 'certificate' from LBMS in about 1989 for LSDM (a proprietary version of SSADM) which was what qualified me to be an Anal Prog¹, and certainly not qualified in C.S. - Praxis rather than Theory. ĸen 1. One of my colleagues used to read out some of the advert titles in the weekly trade rag for jobs in the Thames Valley : "Anal Progs, Berks" and then she would say "I've got a chance, then" ;-) -- Nanny Ogg usually went to bed early. After all, she was an old lady. Sometimes she went to bed as early as 6 a.m. -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
