Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider using longer names #4

Open
eyalroz opened this issue Dec 31, 2020 · 4 comments
Open

Consider using longer names #4

eyalroz opened this issue Dec 31, 2020 · 4 comments

Comments

@eyalroz
Copy link

eyalroz commented Dec 31, 2020

In decades past, it used to be the case that only some characters at the beginning of an identifier were meaningful (after compilation), and the rest were ignored; also, screens showed fewer characters per line. This led people to try to "skimp" on characters in identifiers (e.g. in the Unix file system's top-level directories).

But these days - that's not necessary. And in this particular repository, there are original names to replicate.

Thus, I suggest you consider using the names "vector", "string" "dequeue" etc. in full, rather than the ultra-short versions of them.

@glouw
Copy link
Owner

glouw commented Dec 31, 2020

The real benefit of the 3 letter prefixes is alignment. The names are cumbersome, and having a set of prefixes is a visual aid when mixing container calls. Take for instance the usual, a lst and vec:

typedef char* charp;
#define P
#define T charp
#include <lst.h>

typedef struct { int x, y; } point;
#define P
#define T point
#include <vec.h>

int main(void)
{
    lst_charp a = lst_charp_init();
    vec_point b = vec_point_init();
    lst_charp_push_back(&a, "the");
    lst_charp_push_back(&a, "quick");
    lst_charp_push_back(&a, "brown");
    lst_charp_push_back(&a, "fox");
    vec_point_push_back(&b, (point) { 53, 32 }); 
    vec_point_push_back(&b, (point) { 11, 22 }); 
    vec_point_push_back(&b, (point) { 83, 23 }); 
    lst_charp_free(&a);
    vec_point_free(&b);
}

Juxtaposed with long names, unaligned.

typedef char* charp;
#define P
#define T charp
#include <list.h>

typedef struct { int x, y; } point;
#define P
#define T point
#include <vector.h>

int main(void)
{
    list_charp a = list_charp_init();
    vector_point b = vector_point_init();
    list_charp_push_back(&a, "the");
    list_charp_push_back(&a, "quick");
    list_charp_push_back(&a, "brown");
    list_charp_push_back(&a, "fox");
    vector_point_push_back(&b, (point) { 53, 32 }); 
    vector_point_push_back(&b, (point) { 11, 22 }); 
    vector_point_push_back(&b, (point) { 83, 23 }); 
    list_charp_free(&a);
    vector_point_free(&b);
}

The difference is minute, but the goal is visual alignment to the C++ equivalent of:

#include <vector>
#include <list>

int main()
{
    std::vector a;
    std::list b;
    a.push_back("the");
    a.push_back("quick");
    a.push_back("brown");
    a.push_back("fox");
    b.push_back(point(3, 32));
    b.push_back(point(1, 22));
    b.push_back(point(3, 23));
}

@eyalroz
Copy link
Author

eyalroz commented Dec 31, 2020

The names are cumbersome

That is, I would say, a matter of personal preference (mine is somewhat different).

But - they are the names of the C++ standard library constructs. I don't like a great many things about what's in the C++ standard library, but that's what you set out to implement.

If you just want to implement something reminiscent of the C++ standard library, that's something else I guess.

@glouw
Copy link
Owner

glouw commented Dec 31, 2020

Considering CTL has been released in it's current form, changing name signatures would unfortunately break downstream.

If it's absolutely necessary for your codebase to rely on full nomenclature, do a batch redefine:

#define vec vector
#define P
#define T int
#include <vec.h>
#undef vec

@rurban
Copy link

rurban commented Jan 4, 2021

My variant has proper long names, and does not pollute the main include space.
https://github.com/rurban/ctl

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants