nicrohobak
commented
4 years ago I think I decided against that on the basis of "the things you will need to see most are what should be most readily available at a glance". Basically, I felt the trade-off was best to give the benefit of the ordering to the quick or casual observer/library user and to place this kind of mental "work" on anyone actually developing or working on a deeper understanding.
The idea being, if you're using this correctly, you only really should be using the public members (probably directly as a preference, if fully exposed, hence the placement above public functions even), or the public functions provided as the interface. But, if you need to work on the library or work on a deeper understanding, you're probably going to end up with those multiple windows open and everything anyway since you'll probably also be looking across multiple files, along with whatever you normally would be doing to understand code.
It's not going to be possible to please everyone, so I basically decided it's probably best to please the most-common use case...and that's probably the public interface of any given class, assuming you're using the classes as-intended.
On Fri, 2020-06-05 at 13:49 -0700, Druidpeter wrote:
I accidentally closed the other issue we were discussing on, so I'm opening this one to keep the channel open.
Copypasting your Response: A follow-up thought that may help in reading the code too..
When defining classes, I try to make them as "self-documenting" as possible, but the general philosophy is something like...the closer to the top something is defined, the more likely it will be for you to be interested in it in general use.
So, the definition tends to be something like:
class
public members public functions constructors/operators protected members protected functions private members private functions Protected and private members often get an underscore as a prefix...capitalization is also a factor... I don't remember all of the philosophy I was running with at the time, but there was indeed a method to the madness. Hope this helps too.
I like the scheme you have of public/protected/private ordering going from top to bottom, though may I request a similar scheme with the exception of grouping all members and functions together? Something like:
-public members -protected members -private members -public functions/constructors -protected functions -private functions
My reasoning is that usually when I'm looking for for a member vs looking for a function, my thought processes are usually in two different places. It's mentally helpful and narrows the actual amount of possible 'screen space' I have to search visually to find a member/function if I know it's always going to be above/below all other functions/members, respectively.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.
Druidpeter
I accidentally closed the other issue we were discussing on, so I'm opening this one to keep the channel open.
Copypasting your Response: A follow-up thought that may help in reading the code too..
When defining classes, I try to make them as "self-documenting" as possible, but the general philosophy is something like...the closer to the top something is defined, the more likely it will be for you to be interested in it in general use.
So, the definition tends to be something like:
class
Protected and private members often get an underscore as a prefix...capitalization is also a factor... I don't remember all of the philosophy I was running with at the time, but there was indeed a method to the madness. Hope this helps too.
I like the scheme you have of public/protected/private ordering going from top to bottom, though may I request a similar scheme with the exception of grouping all members and functions together? Something like:
-public members -protected members -private members -public functions/constructors -protected functions -private functions
My reasoning is that usually when I'm looking for for a member vs looking for a function, my thought processes are usually in two different places. It's mentally helpful and narrows the actual amount of possible 'screen space' I have to search visually to find a member/function if I know it's always going to be above/below all other functions/members, respectively.
:edit: Oh! And another thing. Usually my method of organizing code is to reduce as much screen space as possible related to any particular logical chunk as code so that I can navigate visually as fast as possible. I personally do the following things:
I actually got through reformatting achar and uchar along these lines when I realized that it might not be such a good idea to just start changing code formatting conventions like this willy nilly. Please let me know what you think about them. I will stick to your formatting conventions for the remainder of the sources, and will revert my formatting conventions back to yours for those sources already converted if you so desire.