On Saturday 29 August 2009, Duane Ellis wrote: > David Brownell wrote: > > On Friday 28 August 2009, Magnus Lundin wrote: > > > >> So why this totally idiotic requirement on 72-80 columns ???? > >> > > > > Far from "idiotic"... > > I second this. > > The Linux Kernel "coding standards" also has a few very good rules about > indentation width. > > (a) Tabs are 8 - not 4. > (b) Keep lines less then 80. > (c) one function one screen (ie: 80x24)
Worth pointing out that (c) is more goal than reality, and then often for "helper" functions not certain core code. There are state machines where the "case" for one state fits on one screen but there are a dozen such cases per function. The overriding goal is clear and clean code. A better way to put (c) is to keep functions conceptually clean, since limiting to four or five levels of nesting, combined with (a) and (b), nudge "deeper" function into helpers. Folk familiar with cognitive psychology understand that "chunking" is important in how minds work ... it structures long and short term memory. When a function needs more chunks than fit into (human) working memory, it's harder to understand and debug: complex and error prone. Code complexity metrics work on similar notions. > Those three things have a dramatic effect on understanding and readability. > > Tabs & Width = mean you do not suffer indentation sickness. > The Nlines - limit make it so you can read everything on one screen. > > Or as David points out, "you can fit it inside one IDE tiled window". Not that kernel developers use IDEs, as a rule. ;) But they *do* regularly use adjacent windows, where the window manager does whatever tiling is needed (minor overlaps OK, but completely obscuring the reference code is counterproductive). > Some screens are nice and wide, tiny fonts, mine is not - I have to have > larger fonts so I can see. Yeah, that too. Some peoples' eyes are born weak; other people have to age into eyes that need large fonts. Yet others have both problems. I use larger fonts too. :) - Dave _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
