>>4640
Thanks for the explanation Anon, that definitely clears things up for me.
>it's really hard to write function names that are not too long and still make sense XD.
I too deal with this issue (what conscientious developer doesn't heh). I think there are at least 2 or 3 solid engineering principles that help out in general, if you can figure out a way to adopt them:
>1. limit the visible scope of named elements. then they can then be reasonably shorter and still 'make sense'.
>2. take advantage of language features to help reduce any ambiguity.
>3. don't name items at all if possible. eg, use anonymous functions, objects, etc. when reasonable.
I'm writing in C++ not C at the moment, and I'm well aware they are different worlds. One aspect of our software that we both must strive for is clarity of code, as well as robustness of code. I'll try to throw out a straightforward example of what I mean for you. I'm going to use a simple window display via the
FLTK cross-platform C++ GUI toolkit (I'd personally consider it primarily a set of C libraries myself, but that's their official description
https://www.fltk.org/ ). It's remarkably lightweight for a GUI system, just about the best there is for the full feature-set it offers. It goes back quite a ways to the NeXT & SGI and is still under active development today, so it's a good example of a well wrung-out graphics system by this point in time.
So, the FLTK has the notion of a window, whose signature is this (I'll use the double-buffered version as the example here):
Fl_Double_Window(int X, int Y, int W, int H, const char *l = 0)
In practice, constructing one of these windows looks basically like this in C++:
Fl_Double_Window foo_win{100, 100, 600, 400,"foo"};
Not too uncommon, but if you are a newb unfamiliar it's possible you'd mix up your X for your W, or your Y for your H. Heck, even an experienced dev might do this. Since these four ambiguous ints are all about a single
idea namely, a
rectangle, a more solid approach would be to encapsulate them together as such. Further, since the X & Y are really the
origin point for the rectangle shape, they present a second good opportunity for encapsulation together into a point.
Now the window constructor can just talk about it's rectangle and the window title. C++ makes such a thing very simple via inheritance and delegating constructors. If I create a Point and Rect class first, then I can inherit from the base FLTK class into my own Window class like this:
class Window : public Fl_Double_Window
{
public:
Window(const Rect& rect, const char* title)
: Fl_Double_Window{rect.origin.x, rect.origin.y, rect.w, rect.h, title} {}
};
Now when creating a window, what I need to pass as args is a
Rect and a title string. I unpack the Rectangle in the delegating constructor, passing that information on to the base Fl_Double_Window class. While this requires some extra groundwork (three new classes), I think it's clearer in it's meaning at the caller than having 4 unnamed & ambiguous ints as arguments (even if it increases the actual text length at the caller).
Further, ambiguity can be significantly reduced at the calling site by using
designated initializers which specify precisely what values belong to what parameters. And robustness can be enhanced by using inline construction for the statement, which effectively guarantees limiting the scope of the variables to just the construction. Combining these ideas, the resulting call now looks like this:
Window window{
.rect = Rect{.origin = Point{.x = 100, .y = 100}, .w = 600, .h = 400},
.title = "Rect designated inits ctor"};
Definitely wordier, but dramatically improved in terms of maintenance and overall reliability IMO.
Here's the entire working example that puts it all together Anon:
#include <FL/Fl.H>
#include <FL/Fl_Double_Window.H>
struct Point
{
Point(const int x, const int y)
: x{x}
, y{y} {}
int x, y;
};
struct Rect
{
Rect(const Point origin, const int w, const int h)
: origin{origin}
, w{w}
, h{h} {}
Point origin;
int w, h;
};
class Window : public Fl_Double_Window
{
public:
Window(const Rect& rect, const char* title)
: Fl_Double_Window{rect.origin.x, rect.origin.y, rect.w, rect.h, title} {}
};
int main() {
Window window{
.rect = Rect{.origin = Point{.x = 100, .y = 100}, .w = 600, .h = 400},
.title = "Rect designated inits ctor"};
window.color(FL_BLACK);
window.show();
return Fl::run();
}