From: D. M. M. <mic...@ro...> - 2011-10-07 19:56:45
|
On Friday, October 07, 2011, Tom Breton (Tehom) wrote: > How are these classes best fit into files? In my opinion, you can never go wrong putting every class in separate .cpp/h files, and always putting implementation details in the .cpp file, no matter how trivial they are. Whenever I go digging around for something, the two biggest things I notice that waste my time are finding some class stuffed in a file with some other class, and finding the implementation I'm looking for stuffed inline in a header. These aren't stone hard rules, but I think they're both good practices that improve maintainability over time. Sure, you end up with a .cpp file full of trivial stuff that could have been in the header, and you wind up with a lot more .cpp/h files this way, but it's so much easier when you want to find SomeClass::someMethod and you know you're looking for SomeClass.cpp, not SomeClass.h, and not RandomJumble.[cpp|h] (<cough> NotationTypes </cough>). Implementation details stuffed in non-standard places can be surprisingly hard to find, even when you know what you're looking for. So having said that, I wouldn't be especially worried about dumping 12 new files in whatever directory the parent they were forked out of was located, but neither would I object to creating a new subdirectory. It's all good either way. > I think they belong somewhere in src/base since they used by both gui code > (EventParameterDialog) and editor code (SelectionPropertyCommand). I have no strong opinion on this either way, so whatever you think is best will do nicely. > Second, when I read up on tr to understand the freeze better, I realized > there's something called translation contexts that I don't know much > about. Translation contexts are a pain. > My tiny classes above call tr but aren't derived from QObject. > Should I: I'll probably end up using QObject::tr() to get those translations working, but you and everybody else can just leave that junk to me. I ask everybody to wrap their user-visible strings in simple tr() calls, but I don't expect anybody to worry about it beyond that. I'll find and fix these problems later on in the process. It's always a big mess. -- D. Michael McIntyre |