| Thread Previous • Date Previous • Date Next • Thread Next |
WinEDA_ as a prefix was not a very good idea. but I think a prefix (I used Ki_ (shorter and more meaningful) in some last created classes ) is useful to identify what is a kicad source, and what is an other source (like the kbool library). wxWidgets does that, and it is a good idea (assuming wxWidgets authors are not beginners).Maybe "ki", like "kiPrintOutput"? I personally prefer class names as CamelCase with capitalization of all words, but it this case this would be a prefix. Prefixes are important in libraries, but do we really need them in KiCad main code? Michal
If wxFormBuilder were to be used, then the discussion could be limited to two class names per dialog window. But let me stray briefly to state some general preferences first. I prefer *all* upper case class names, not just first letter of each word. The reason is that this distinguishes class names from function names, for which I prefer the upper case first letter only. Any prefix should be indicative of function or purpose. I think using Ki_ is not providing value here, since it does not indicate function or purpose. But I am not opposed to prefixes in general.
Regarding the two classes per dialog, one of which would be derived from the other, we might think about adopting a pair of prefixes to show that these two classes are related and share a common purpose by way of a common basename, for example, with "basename" being variable per such pair:
fbr_basename.cpp holding a class with name FBR_BASENAME autogenerated by wxFormBuilder
dlg_basename.cpp holding the class derived from FBR_BASENAME with name DLG_BASENAME which has the hand coded event handlers.
fbr_xyz.cpp and dlg_xyx.cpp would always be considered part of a set implementing the dialog window. dlg_xyx.cpp in a rare case might not be needed if there were not custom event handlers.
Could we agree on such a scheme, if JP were to accept the wxFormBuilder? Dick
| Thread Previous • Date Previous • Date Next • Thread Next |
