Quoting robert engels (2018-11-24 17:06:29) > I would argue that good code reads in a linear manner - if it doesn’t > it is a problem with the programmer or the language syntax/grammer.
I think this is true on a small scale, but... > On Nov 24, 2018, at 3:28 PM, Dan Kortschak <dan.kortsc...@adelaide.edu.au> > wrote: > > An interesting point here is that natural language writing like > > reference manuals actually do often include things similar to syntax > > highlighting where key points are bolded, underlined or italicised in a > > manner broader than is common in prose. When looking at a larger codebase, I am typically interested in specific aspects of the code, because I'm trying to either do or understand a particular thing. I'll likely read a function definition start to finish, but not typically a whole file. At the level of packages it's not clear what the start and finish even are, but I'll usually only read part of it. The reference manual analogy actually goes really deep here I think. If a large codebase must be read start to finish, it's probably a sign that there's too little encapsulation -- good code should let you understand it without having to think about more than a few things at a time. -Ian -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
