I've been programming on and off for over 45 years, I loathe camelCase. Personally I find camel case very hard to read - which is probably me. I've programmed in C, and COBOL, and Pascal and Python and so on. For me, clarity, intent and readability are far more important than saving a line here or there,  white space literally gives me space to think.. So: I modularise practically everything, where I can, and they go into reusable library modules commented, and include them. The opening brace [generally] goes on the same line. I indent and newline children, whether inbuilt children or modules. The closing brace is always [generally] indented to the same level as the start of the line which opens the brace. The closing brace is ALWAYS commented e.g. }//end module or }// end diff. Variables_often_contain_underscores - because it helps MY readability. Two letter variables are reserved for, well reserved meaning - e.g. differencing two objects which have one or more matching dimensions causes lots of compute time to resolve the overlaps, so I assign a consistent variable which always represents a small delta in axis direction or dimension, and for 3d printing, a simple pa - for print allowance - to increase the size of holes to compensate for undersized holes. But I learnt to touch type in 1984 [honest, it really was 1984, me, a friend, and about 20 others, on real typewriters]. That hour a week at nightschool, for about eight weeks, nearly 40 years ago has repaid itself many thousands of times over thru a 40 year career in messing with computers for a living. I find my biggest hurdle is remembering the scope of variables can bite, and finding where the value has been overwritten can be tricky, so underscored prefixes to define scope helps. Oh and tabs, always tabs. Reading other peoples code with cryptic short names and camelCase is PainFul, but I have learnt so much from reading other peoples code, its just the price of learning IMHO. Roger.