Luke Gorrie wrote: > I want to order my functions in parent-to-child depth-first order, > because that's the order I want people to read my source. What's the > case against this? 1. Does not work with local function declarations. 2. Code reading order is rarely linear, anyway. 3. Editors. E.g. 'gd' in vim ('go to definition', upwards of course). 4. Nobody else does it. Neither in C nor in Lua. Corollary: Few people will want to collborate with you on your source code, since it's confusing for them. > > * Don't use packed structs that don't need to be packed. > > I'm using a conservative definition of which structs need to be > packed: all the ones that must be laid out in memory exactly as > written. Reasonable? Nope. The alignment of packed structs is set to 1. This basically forces all accesses to be unaligned loads/stores. LuaJIT ignores that for now (implying: don't do that if you're on a machine that requires aligned access), but it might do (expensive) unaligned accesses in the future. C99 and the ABI already specify how structs are to be layed out. There cannot be any gaps if all fields are naturally aligned. > :-). 3 spaces is from lua.el defaults and spaces before parameters is > from the style in Programming in Lua. Are there multiple schools of > thought on this? See above: if you want others to work on your source ... [The space before parameters is local 'Rio' style. I haven't seen this anywhere else before. Semantically speaking it's nonsense. That's right on par with putting parenthesis around return values, indenting 'case' in C (and not its contents) and other horrors. Indentation and spacing conveys intent. And intent should follow language semantics: scoping, block structure, labels, statements vs. expressions, definitions vs. calls, etc. It may be hard for a beginner in a certain language to recognize the patterns. But experts will readily spot the disparity and get annoyed about your source code.] --Mike