Naming conventions

Help!
1

I’ve recently watched Markus Triska’s video on appropriate naming conventions: Naming Prolog Predicates

I’m now trying to be a bit more careful about following these conventions in my code. However, one problem that I’m running into in attempting to name relationally is that I often want to use an adjective or two-word or even three word phrase. For instance:

user_capability_authorisation(User_Capability,Authorisation) :- 
    ...

Here it is somewhat ambiguous whether we have user_capability or capability_authorisation. Ok, I’ll admit here it’s not so confusing, but in the TerminusDB code base we have a number of predicates that look like graph_descriptor_transaction_objects_read_write_object/3 (sic) in which it is not so easy to parse!

How do people generally cope with this issue? Mixing snake and camel-case seems somewhat evil, but I’m tempted.

1 Like
2

My guess it is means

graph_descriptor_transaction_objects__read_write_object/3

If this is correct, adding a well placed additional _ is better than camel casing.

Personally I like longer names. If you start to reach the other extreme you wind up with code golf or APL. (TryAPL)

2 Likes
3

Very close!

It’s actually

graph_descriptor__transaction_objects__read_write_object/3

Might actually go with that strategy.

1 Like
4

Some standard abbreviations seem reasonable to me. E.g. graph_descr__xactn_objs__rw_obj/3 – and possibly the final _object isn’t needed at all?

1 Like
5

A programming “style” is one of those very personal things. Choosing a style and sticking to it can have unexpected consequences (I’d almost call it “emergent behavior” but I am not 100% sure what “emergent behavior” really means).

(Sorry, can’t watch a video now so making assumptions about what is really suggested… correct me if I misunderstood or maybe there is an article with similar content you could link?)

To recap: “Relational” predicate names means that instead of length/2 we have list_length/2 and instead of select/3 we have element_list_rest/3 and so on, right? So basically the names of the arguments are extracted from the argument list and stuffed into the predicate name:

length(List, Length)

becomes

list_length(L, N)

Naming “fact tables” is where this shines, because the argument name might be missing altogether in the program source:

% person_birthdate(Person, Date)
person_birthdate(mike, date(1984, 4, 14)).
person_birthdate(marian, date(2001, 12, 2)).

(Comment was unnecesary!)

I have attempted to follow this naming convention strictly also for predicates (not just pure data), and this had the following side-effects (is that “emergent behavior”?):

  • My variable names decreased in length until they became one letter each;
    • When the first letter of the real argument name was duplicated, as in list_length(L, L) oops! I started developing an ad-hoc system of rules on how to resolve those conflicts and still keep the argument names relatively short…
  • I tried (hard) to make the predicates true relations even if there was no obvious short-term benefit of doing so (sometimes you really want to just find the average or split input into lines “but isn’t it cool to enumerate lists of numbers that have that average… or maybe list of integers are good enough… why integers though? what about rationals, those can be enumerated, right?.. but floats can also be enumerated!” and so on);
  • I tried to keep the number of arguments per predicate relatively low for obvious reasons;
  • I even started getting creative with how I name things and developed an ad-hoc system for abbrvtng words that were seemed too long at the momnt (there have been such systems in use long before computers existed, it turned out, so there is a whole other world of conventions to source ideas from).

Whether these side effects are limited to me only or can be observed in other programmers, I don’t know. Whether these side effects are good or bad (for me? for my program?) I also don’t know.

1 Like
6

Agree. Typically only for either abbreviations everyone uses (rw for read/write, io for input/output, x/y/z for coordinates, etc) or project abbreviations for terms used all over the place and which everybody involved in the project thus quickly masters. And, especially for local predicates the context may make shorter names acceptable. Overall, I think shorter is better as long the name doesn’t become ambiguous. Problem is that it is hard to judge where ambiguity starts :frowning:

1 Like