STYLE: Distinguish ivars from local vars

[hjmjohnson]

A common method for improving code readability
is to conform to a standard naming convention
for class & struct ivars. The two most prevalent
mechanisms for accomplishing this are:

1. ITK/VTK and many other projects
   ivars beging with "m_" for object ivars, and "s_"
   for static class ivars.

2. Google Style
   ivars are suffixed with "_"

This practice reduces burden of maintenance for
community developed software by inherently providing
contextual and intent information directly in the
variable name.

[hjmjohnson]

@fbbdev Fabio,

I think this project has great potential. I am making recommendations early in the project regarding some style and conventions that will have long term benefits of cultivating a vibrant user and developer base.

Please consider this recommendation. If you are satisfied with these changes, I can work to implement them over the next few days.

Regards,
Hans

[fbbdev]

Hans,

I'm fine with these changes as long as struct members and public class members retain normal names (as recommended by the Google Style Guide). So in structs (like Point, Rect and others) we should still change method argument names in order to avoid shadowing.

If you're fine with the above requirement, go ahead with the implementation; I will avoid changing class members until I get your pull request, in order to minimize conflicts.

Thank you for your interest in this project :)

[hjmjohnson]

@fbbdev Fabulous. I think your proposal is perfectly balanced between pragmatic and conformant.

[hjmjohnson]

@fbbdev
I want to bring your attention to:
https://google.github.io/styleguide/cppguide.html#Structs_vs._Classes

This is a fairly common approach to managing structs and classes.

I would recommend converting the "Color" struct to a class.

Do you have a counter argument for your distinction between classes and structs?

Hans

[hjmjohnson]

@fbbdev

This now has private class ivars with suffix of "_".

[fbbdev]

@hjmjohnson I definitely agree with google's distinction. Yet I interpret it more liberally:

Methods should not provide behavior

Color is plain data and its methods do not provide behavior; they are operators, or, if you like, getters for computed properties. They could be implemented as external functions, but I made them into methods to make code more terse and allow quick pipeline expressions like e.g. some_color.premultiplied().green(0.4f).hue() in place of plot::hue(plot::green(plot::premultiplied(some_color), 0.4f)). Also, I generally lean towards a functional programming style where data is never mutated in place when not absolutely necessary.

A similar case is block_t in braille.hpp. Again block_t is just a data block and its methods except maybe clear and set implement unary or binary operations on said data. clear and set are tolerated there because they provide fine-grained access to pixel data.

On the other hand image_t is a container exposing memory allocation behavior, so I made it into a class.

I understand the phrase 'provide behavior' as if meaning 'have side effects' or 'implement control logic'.