@merlin is working on some interesting ideas to change key positions/addresses from two byte storage to one byte, in order to safe memory. When discussing with him, I was reminded about some related aspects that could be improved in Kaleidoscope. In order not to forget them, I will summarize most o…

@jesse & @algernon : Is there a plan for converting names (among other things, but variable names really stand out to me) to match the style guide at some point? Also, the style guide currently says that class data members should have trailing underscores, but struct data members should not. I think…

Another question: Would it be helpful if plugins each used their own namespaces, such that everything in plugin Foo was in the namespace kaleidoscope::foo? This seems logical to me, but as is surely clear by now, I’m no C++ expert. :wink:

[image] merlin: Is there a plan for converting names (among other things, but variable names really stand out to me) to match the style guide at some point? Yes, but the style guide isn’t finished yet, either. [image] merlin: I think it has been indicated somewhere in a PR that the disti…

[image] algernon: If Kaleidoscope-Something is in the kaleidoscope::something namespace, and the class is also Something, that seems repetitive. I thought of this shortly after I wrote up my query. Since the class is basically already a namespace, it does seem unnecessary. [image] algerno…

[image] merlin: Here’s one situation that might benefit from a plugin namespace: if a plugin library consists of multiple classes (one of which is the plugin itself). It would be nice for them to all share their own namespace. Maybe the plugins could all be class kaleidoscope::something::Plugin?…

[image] algernon: Yeah. There seems to be an agreement that public should be data_member, private should be data_member_. As structs are public, their members should not have a trailing underscore, indeed. I would simplify this. Just add an underscore to all class data members. The whole poin…

[image] noseglasses: I would simplify this. Just add an underscore to all class data members. The whole point of the underscore is to make it easier to see if a variable is a class member or a global, in case its not a function argument. This helps to determine quickly where a variable is define…

[image] merlin: (and in a less constrained environment, there’s very little reason to have public data members, so the distinction shouldn’t matter) There is no reason at all to have public data members. Not because of constraints of the environment. When inlined, setters and getters do not c…

Don’t setters and getters require copy operations that can sometimes be skipped with direct access, even if the code is inlined? And I would argue that if I have a class with a data member that I want other code to be able to read and write without restriction for performance reasons, the only reas…

[image] merlin: Don’t setters and getters require copy operations that can sometimes be skipped with direct access, even if the code is inlined? Inlined setters and getter can be optimized by the compiler in a sense that they virtually disappear.

Kaleidoscope's implementation - possible improvements

Programming

noseglasses (Noseglasses) December 15, 2017, 3:53pm 24

Topic		Replies	Views
Why use properties instead of setters/getters? Programming	19	3929	December 16, 2017
Kaleidoscope's use of C++ features and idioms Kaleidoscope Internals	28	2603	June 25, 2018
How to propose changes to Kaleidoscope's internals or design Kaleidoscope Internals	14	1551	November 6, 2017
Single-byte key addressing (for boards with fewer than 256 keys) Kaleidoscope Internals	90	4665	December 16, 2017
Kaleidoscope-CMake Programming	19	3102	December 9, 2017

Kaleidoscope's implementation - possible improvements

Related topics