2021-04-09 13:17:08 I've been thinking about field naming conventions …

[qmacro]

I've been thinking about field naming conventions today, after the pleasantly opinionated threads on Twitter.

I expressed that I like the old 5 character (usually uppercase) field names that appeared with R/2. Anyone who's been working in the SAP ecosphere will know what I'm taking about, fields like BUKRS, LIFNR, MANDT, WAERS, and so on.

For me, there's a certain beauty about them, a uniformity and a neatness that I haven't seen elsewhere.

Of course, this beauty can't be seen by some folks - they express a preference for longer names, but for me, those longer names are ugly, bring about a requirement for extra brain cycles to determine whether they should be camelCased, TitleCased, kebab-cased, snake_cased or some combination thereof.

And what about how long they're allowed to be, or how short? There's another decision right there. Moreover, it's often the case that naming conventions are loose, so you see all sorts of ugly mismatched cases for variables scattered throughout code.

Worst of all though are those variables that are so long (I'm thinking longer than 10 chars, that's double what my favourite style restricts itself to) makes code much harder to read. For me it's similar to reading a paragraph of prose when it's stretched out across the width of a widescreen monitor. Very hard on the eyes and the brain. There's a reason newspapers print articles in narrow columns.

There's more. I've not even got on to prefixes. Hungarian notation, anyone? What do you prefer there? And should the prefix be separated by some sort of symbol, or be part of the variable name directly?

Moreover, some folks have expressed an opinion (to which they're naturally entitled, we all are) that fields like BUKRS, MANDT and so on are restrictive because they're short forms of German words, and that's a barrier to entry.

When I started in 1987 in the SAP world, with R/2 4.1d, I was awash with these field names. What's more, I didn't speak a word of German. But it wasn't a problem - the brain is good at pattern matching in the first instance, and then when I had time, I looked up what they meant. BUKRS - Buchungskreis - Company Code (posting area). Right! And that served only to strengthen the slot in my brain that remembered that field name.

This argument reminds me of an exhortation I saw the other day in a handbook for writing documentation, or even blog posts. Write using simple words, in simple terms. To be honest, I find that ever so slightly insulting to the reader.

English is my first language. I could say that German is my second language, and that's pushing it, a lot. While I was learning German in the early days (mostly by osmosis), I used to read technical articles and came across words that I hadn't seen before. Guess what? I looked them up, and my knowledge expanded. Not only relating directly to that word, but also to other future words that shared the same root.

Anyway, what am I saying here in this journal entry? I guess, at the end of the day, it's a lovely first world problem - debating what convention we prefer for our field names. It's pleasant to discuss, expressing our opinions is a healthy way to pass the time, and helps me keep sharp, as there are always great alternative opinions out there that challenge my thinking. And I like that. For me, sharing my thoughts, having them challenged, and learning - that's what it's all about.

And for those who still can't figure out why I like the 5 char uppercase names, it's because they don't have all the problems that longer, mixed case names have, that I described above :-)

[DStinnett-Christy]

I totally agree on the upper case part of your argument. When I first started working with databases, about 30 years ago, the dbs I worked with required the field names to be all upper-case. I definitely find them easier to read. However, limiting them to 5 characters is a challenge - I like field names to "document" the data they contain, but in a short, simple form that sometimes is difficult to limit to 5 characters.

It seems to me that what you prefer and what I prefer are both based on the patterns we learned when we first started working with databases

[qmacro]

Hey @DStinnett-Christy thanks for the comment, I appreciate it! I think you point out an important part of this whole discussion, and that is what one first encountered, in the "formative" stages. That makes a lot of sense, and yes, I think that's why I still like all-uppercase.

Folks have said that the 5-char names are not expressive enough, not descriptive enough. And that's fair, I didn't at first either, when I first encountered them. But after a short while their expressiveness started to shine through, because they were just short form for longer words and phrases, e.g.:

WAERS -> WAER-S -> Waehrungsschluessel -> Currency key

That to me is the ultimate combination of conciseness and expressiveness.

Some folks react with "well it's in German". My response to that is to think about other words or expressions which they likely use, or at least see, on a daily basis, expressions that are in a different language, yet they don't bat an eyelid when seeing them. I used one earlier, sort of deliberately, too:

e.g. -> exempli gratia -> for the sake of an example -> for example

Another example of the ultimate in conciseness and expressiveness. And it's in Latin.

[123go]

At the risk of entering another "my grey hair is greyer than your grey hair" thread that, with your experience and my baldness, I am bound to lose both figuratively and literally... :-)

I cut my SAP teeth in R/2 and I think that is why I don't like extremely abbreviated names. I remember creating new database fields and trying to think of 5 character names that conveyed some meaning - and too often failing miserably. Yes, I subconsciously know that BSEG-ZUONR is the assignment number field for an accounting document item but I didn't when I first saw it. And there are plenty of new folk for whom learning SAP tools and processes is enough of a burden, let alone having to rote learn a bunch of abbreviated German terms. If I had to choose between BSEG-ZUONR and ACC_DOC_ITEM-ASSIGNMENT_NUM then I'd choose the latter. I do understand where you're coming from though. Beauty can lie in brevity and there is such a thing as a name that is too long... but I think we should avoid both extremities. Thanks for the interesting discussion!

[qmacro]

Thank you @123go for adding your thoughts - this is of course a light hearted and subjective discussion, and I value what you have to say.

Us grey haired R/2 dinosaurs (that's a compliment!) need to stick together, regardless of field naming opinions :)