Forum > General

Naming conventions for libraries and 3rd party units - prefixing names

<< < (2/2)


--- Quote from: SuperSathanas on May 21, 2024, 03:34:51 pm ---I've done some searching around here and through several Google searches, and I'm not really seeing an answer to my question, so here we go...

Is there any sort of accepted/expected naming conventions specifically for libraries or just 3rd party units in general, insofar as naming them in such a way that they are easily identified as being from those units? I don't mean things like prefixing type names with "T" or the intended usage of "Get", "Set", "Do" and whatnot.

--- End quote ---

That is roughly the Delphi/Borland style guide for Object Pascal. E.g. Pascal in general has a unified namespace for all symbols, types, functions, constants etc, so it is a good habit to prefix types with  "T" , to leave the core identifier free for use as variable or fieldname.

--- Quote ---I'm talking about how in the BaseUnix unit, most functions are prefixed with "fp", although I get the feeling that the only reason some of these units that ship with FPC that have use this kind of naming is because they are based on or translated from equivalent C headers that used the same or similar prefixing.

--- End quote ---

That and the socket unit is something different. The main reason is that there are many POSIX names that are reserved identifiers or core library functions (read, write, close), and many were very generic words (like wait and send() that are also very  common)

In an older Linux interface, only some of those were escaped, and it constant caused questions and confusion, so it was decided to prefix in the new environment to get rid of that, and have a consistent prefixing.

Posix, Unix_ and Unx_ were rejected (Posix is wrong as Pascal won't interpret C headers, so Posix source compatibily isn't guaranteed the same way it is on C). APIs like the sockets unit are not Unix only, and Unix is a trademark. So in the end a short prefix was chosen. "fp" without hyphen. I think it originally meant "FreePascal Posix", but I'm not entirely sure anymore. (I favored unx_ back then)

--- Quote ---I do this primarily so that I can identify what is coming from my own units, and also avoid naming conflicts (System.Move and ncurses.move come to mind). My naming style is pretty C-like, I like to think, simply because I learned my conventions from C and C++ before ever touching Pascal, and Pascal is pretty C-like itself in many ways.

--- End quote ---

Yes, somewhat, but due to the Pascal unit/namespace system, clashes are a bit rarer, and bit less absolute than in C (where symbols can clash at the linker without being otherwise related). Specially if the API uses very generic identifiers.

So it is only a convention/best practice however, and in no way enforced.

--- Quote ---Edit: I guess I should also ask if there are any good reasons to not name things this way. I could just not and then I or some hypothetical user could just unitname.function, but then in my head that still leaves the possibility of using the wrong function from the wrong unit, and also makes the code look inconsistent, specifying unit names in some places but not others. Maybe that's just one of my personal hang ups, what with being used to C++ namespaces (std::function, glm::vec3, etc...).

--- End quote ---

I think it is mainly a evaluation of the chance on clashes. Is it a very generic unit to be imported in many units? (like baseunix and sockets on Unix) Does it contain very common identifiers? Do you intend to distribute widely ?

If all yes, a prefix is best. If all no, probably better not. If in between then it depends.....  :)

E.g. the Windows API don't have prefixes. Partially because the concept is older (Delphi...).


[0] Message Index

[*] Previous page

Go to full version