> Rindfleischetikettierungsüberwachungsaufgabenübertragungsgesetz (“beef labelling regulation and delegation of supervision law”)
Funnily enough, this is mistranslated. It means "beef labelling supervision (task) delegation law". The "regulation and" incorrectly changes the meaning, there are no regulations being defined per that word.
The mistake likely originates from the full name of this law, "Rinderkennzeichnungs- und Rindfleischetikettierungsüberwachungsaufgabenübertragungsgesetz", where the first part is "cow* labelling and…"
* Live animals, only the 2nd part is about meat products.
(It was all about tracking the origin of meat products, was a state law in one of the federal states of Germany, and was in force from 2000 until 2013.)
P.S.: there is some fancy hyphenation happening in that word! Make your window narrower ;D
OT: What are the rules for forming the abbreviated forms of the German laws?
For example [1] lists Rindfleischetikettierungsüberwachungsaufgabenübertragungsgesetz abbreviated as RflEttÜAÜG. I've receently had to deal with some German forms and after introducing the abbreviation in the first paragraph, the applicable law is usually referred to by that abbreviation.
I have no idea which are the rules, but in your example all the capitalized letters of the abbreviation are the initial letters of the standalone words that compose the name of the law.
For the first two words, a couple of additional consonants from the body of the word are added, to reduce ambiguity.
Pretty sure there are no "rules", it's just a general pattern of component initials, disambiguation, but also retaining content if possible. (E.g. it's BNetzA, not BNA... And BVerfG and BVerwG might be needed to disambiguate but they also retain content...)
My complaints against long names are: 1) It becomes harder to see the shape of the code. 2) It often becomes harder to tell different names apart (if they only differ in the middle, for example). Well-chosen (optimistic, I know...) short names are often easier to read than long ones.
This is what I like about Java: There is a culture of giving things descriptive names with very few abbreviations. Compare this with Go, where you can find tons of ugly C-style abbreviations.
But in Germany we are also very good at finding funny abbreviations. For example, the state's tax software is called ELSTER. ELSTER stands for „ELektronische STeuerERklärung“, which, funnily enough, is a thieving bird. The english bird name is magpie.
The name actually makes sense in both directions. As taxpayer you might see the tax office as thieving magpies. And as tax office you might see a software that is used to reduce the tax load of a taxpayer as the sneaky thief. With this in mind, it actually makes sense that someone on the tax receiver's end would greenlight such a name.
All of my code looks like this. I don't want to have to remember what some acronym or partial word/abbreviation means six months after writing it. I don't think "shorter variable names saves typing" is a compelling argument to me. You usually only type it once, but you always end up needing to read through the code several times.
Code golf variable names are intolerable. But there's a happy medium. If you name all your variables like "Rechtsschutzversicherungsgesellschaften", note that I am still a violent psychopath and I know where you live.
Just think of German as a bimodal language. The first is a language with cases, pronouns, word order. Thesecondissimplyyoudisregardspacesandstickthewordstogether. Both are perfectly valid and expected while dealing with this language. As you mentioned insurances... they like them as well a lot, anything overlapping both legal and insurance domains is a true climax.
That's fine for German, but in source code I don't want any variable called LegalProtectionInsuranceCompanies. It takes up too much brain space for me to parse and understand each time. Much rather it was called "lpic" with a comment expanding it at time of definition.
I just want to point out you are saving 3 characters on the last one while making it a fair bit harder to understand. fileName is perfectly fine. fName could be firstName, fileName, finalName, foundName...
> Rindfleischetikettierungsüberwachungsaufgabenübertragungsgesetz (“beef labelling regulation and delegation of supervision law”)
Funnily enough, this is mistranslated. It means "beef labelling supervision (task) delegation law". The "regulation and" incorrectly changes the meaning, there are no regulations being defined per that word.
The mistake likely originates from the full name of this law, "Rinderkennzeichnungs- und Rindfleischetikettierungsüberwachungsaufgabenübertragungsgesetz", where the first part is "cow* labelling and…"
* Live animals, only the 2nd part is about meat products.
(It was all about tracking the origin of meat products, was a state law in one of the federal states of Germany, and was in force from 2000 until 2013.)
P.S.: there is some fancy hyphenation happening in that word! Make your window narrower ;D
OT: What are the rules for forming the abbreviated forms of the German laws?
For example [1] lists Rindfleischetikettierungsüberwachungsaufgabenübertragungsgesetz abbreviated as RflEttÜAÜG. I've receently had to deal with some German forms and after introducing the abbreviation in the first paragraph, the applicable law is usually referred to by that abbreviation.
1: https://de.wikipedia.org/wiki/Rindfleischetikettierungs%C3%B...
That's where the Abkürzungsverzeichnis comes in, though I hope I'll never need to write one for a codebase...
SAP varchar6 name and siemens plc want a conversation about abbreviations as the guilds moat and memory saviour
I have no idea which are the rules, but in your example all the capitalized letters of the abbreviation are the initial letters of the standalone words that compose the name of the law.
For the first two words, a couple of additional consonants from the body of the word are added, to reduce ambiguity.
These seem like sensible rules.
Pretty sure there are no "rules", it's just a general pattern of component initials, disambiguation, but also retaining content if possible. (E.g. it's BNetzA, not BNA... And BVerfG and BVerwG might be needed to disambiguate but they also retain content...)
My complaints against long names are: 1) It becomes harder to see the shape of the code. 2) It often becomes harder to tell different names apart (if they only differ in the middle, for example). Well-chosen (optimistic, I know...) short names are often easier to read than long ones.
This is what I like about Java: There is a culture of giving things descriptive names with very few abbreviations. Compare this with Go, where you can find tons of ugly C-style abbreviations.
This is also the crux with all idention based languages .
But in Germany we are also very good at finding funny abbreviations. For example, the state's tax software is called ELSTER. ELSTER stands for „ELektronische STeuerERklärung“, which, funnily enough, is a thieving bird. The english bird name is magpie.
The name actually makes sense in both directions. As taxpayer you might see the tax office as thieving magpies. And as tax office you might see a software that is used to reduce the tax load of a taxpayer as the sneaky thief. With this in mind, it actually makes sense that someone on the tax receiver's end would greenlight such a name.
All of my code looks like this. I don't want to have to remember what some acronym or partial word/abbreviation means six months after writing it. I don't think "shorter variable names saves typing" is a compelling argument to me. You usually only type it once, but you always end up needing to read through the code several times.
I used to do this with filenames during bioinformatics analyses. Every step of the analysis was in the filename, so I'd get
oyster_results.filteredMAF0.05_filteredHWE0.05_etc._pp_.vcf.gz
I stopped doing that once I learned about file system-specific filename length limits...
13. Dont design ides, compilers and languages that punish you for good,long names. Having the best of identions, will not cut it.
Code golf variable names are intolerable. But there's a happy medium. If you name all your variables like "Rechtsschutzversicherungsgesellschaften", note that I am still a violent psychopath and I know where you live.
Just think of German as a bimodal language. The first is a language with cases, pronouns, word order. Thesecondissimplyyoudisregardspacesandstickthewordstogether. Both are perfectly valid and expected while dealing with this language. As you mentioned insurances... they like them as well a lot, anything overlapping both legal and insurance domains is a true climax.
That's fine for German, but in source code I don't want any variable called LegalProtectionInsuranceCompanies. It takes up too much brain space for me to parse and understand each time. Much rather it was called "lpic" with a comment expanding it at time of definition.
Class names are a separate discussion.
Indeed.
The problem with long var names is that formulas become unreadable and function names take away horizontal real estate for their args.
There are so many ways out to make it shorter yet readable.
- idx is often used as index.
- An event handler can start with On.
- Simply take the first 3 or 4 letters of every word. simpToReadVar
- keyISR Keyboard Interrupt Service Routine
- fName file name
I just want to point out you are saving 3 characters on the last one while making it a fair bit harder to understand. fileName is perfectly fine. fName could be firstName, fileName, finalName, foundName...
fn or fqpn should be well understood too given the context.
You are right!
You probably should avoid working for a German company practising domain driven design in Java.
I've seen code that named classes and variables much worse than that.
As with anything the right answer is probably somewhere in the middle
[dead]