[sldev] Refactoring and development economy

[Felix Duesenburg]

Not sure if this has been talked about before, but wouldn't it make 
sense to implement some more design patterns to reach any degree of 
order that is better than the current one:

- Strictly one file per class, no more and no less. I.e. a header/body 
pair since we're in C++. The filename is always the class name in lower 
case.
- Headers are for declarations, the body for code. There are too many 
headers containing all kinds of things.
- Avoid global functions and variables like the pest, i.e. anything 
except 'main'. It's especially bad to sprinkle them in between class 
methods. Instead, create toolkit classes with static methods and 
variables, or place them in a base class of the part of the application 
where it makes sense to find them.

Naturally, this is coming from someone who has been doing Java a lot. I 
know it is so easy in IDE's like VS to just right click and 'find 
definition' to have a look at that function regardless whether you know 
where it is. But isn't this rather inviting chaos than helping to tame it.

I'm not proposing to change that in one concerted effort, this would 
severely disrupt development. It should be a gradual process, performed 
a class at a time whenever a piece of code is touched.

This wouldn't help just any OS hacker laying their paws onto the source, 
but would make real business sense making navigating easier for LL's dev 
team, also reducing the time they have to pay someone for going through 
the learning curve in case of staff turnover or enlargement.

Discard in case I'm found talking utter rubbish. The thought that 
sparked this was a set of questions that I guess every OS'er is asking 
themselves: Do I refrain from fixing anything that isn't directly 
broken, or do I try to make it better anyway, which may be a subject of 
personal preference if it hasn't been openly discussed? Do I dare to 
undo things someone else has done, since I often don't know whether 
there's a reason for it being that way? Do I try to minimize my patches, 
even if it means adding to a convoluted mess?

More generally than the above, I'm wondering if a series of JIRA's on 
refactoring certain parts of the viewer would attract enough attention, 
or even patches. But it would probably be better to discuss this there, 
since it encourages to keep threads on topic better than this list does. 
On the other hand, the list triggers replies since the messages get 
shoved into everyone's face, on JIRA you have to search for it. What to do?

It was recently mentioned that some at LL are working hard on this. It 
would be great to have some more communication on where the effort is 
directed, which parts are already being tackled and which are in the 
pipeline, and what it's intended to look like. This would be valuable to 
know outside, since I foresee that some of my ideas, should I get them 
done in time, will result in patches clashing with a refactoring effort 
somewhere, and therefore cause extra workload in adapting and debugging 
if we ever want to have them implemented. Then maybe I'm the only one 
thinking that way.

Felix