Friday Finking: Source code organisation

[Barry Scott]

> On 28 Dec 2019, at 22:49, Chris Angelico <rosuav at gmail.com> wrote:
> 
> On Sun, Dec 29, 2019 at 9:37 AM DL Neil via Python-list
> <python-list at python.org> wrote:
>> 
>> Is it helpful to, and thus, do you have a style/convention for ordering
>> the methods within each class in your code?
>> 
>> A major difference however, is that if our mythical collection of
>> module-functions has an internal-reference, eg b() requires a(), then
>> function a() MUST exist, ie be defined, 'before' function b(). Whereas a
>> class's methods may be defined in any (complete) sequence.
>> 
>> So, do you have an orderly method [hah!] for presenting/locating
>> class-methods (and module-functions) within your code?
>> 
>> - why bother, the editor does 'the heavy lifting'
>> - dunders to the fore
>> - alphanumeric sequence by name
>> - order of appearance/use in 'mainline code'
>> - as they sprang to mind during TDD-creation
>> - most-used first, least-used last
>> - my code 'at the top', their stuff later...
>> - names of Monty Python characters by TV appearance date
>> or,
>> - some combination of ideas
>> and,
>> - how do you vary the above when dependencies intrude?
>> 
> 
> "Define before use" is a broad principle that I try to follow, even
> when the code itself doesn't mandate this. This generally means that
> "if name is main" is the very last thing in the file, and if there's a
> main() function or equivalent, that's usually just before that. Any
> metaprogramming goes right at the top; sometimes this is mandated (if
> I write a decorator function, it has to be above the functions it's
> decorating), but even if it's not, metaprogramming goes before the
> mainline.



"define before use" is basically email top-posting for code isn't it?

It means that the first things that you read in a module are the least interesting.

I prefer to follow the a top-down design approach. Start with what is important
and put what that depends on further down the file/class.

With classes, __init__, __new__ then the public API and last the supporting code.

Barry



> 
> Other than that, I don't have any consistent logic other than a loose
> idea of trying to keep related things together.
> 
> ChrisA
> -- 
> https://mail.python.org/mailman/listinfo/python-list
>