Recent searches
Search options
@dgoosens@phpc.socialFor non English speaking coders...
Especially if working in #DDD
#UbiquitousLanguage requires common language & terminology in code and business
Yet, I see many benefits of coding in English....
- code homogeneity between public front end and internal code
- easier to find subcontractors
- English kinda is _the_ standard
- devs are more used to it
- pear review
- "auditability" (For context, my company's lg is FR... but HQ is British)
- ...
What do you do ?
(Boosts appreciated)
@dgoosens code in mostly English, but I've decided that loosely translating Norwegian concepts (I work with cadastre-data a lot) makes no sense.
So, I might use a variable named selectedKommune instead of selectedMunicipality for example.
Makes a lot of sense
But then wondering (and don’t know how NO grammar works)
But will you follow EN grammar rules or NO ?
for instance, in FR I would write
getIdFrWord(),
in EN, that would be getFrWordId()
(I prefer the latter myself)
@dgoosens mixing grammar is difficult, yeah. But no/en is pretty similar in terms of grammar, so rarely a problem. Plurals can be a challenge, for sure, but I think I tend to treat Norwegian words as loanwords in English and thus follow English grammar rules...
@dgoosens On my current project we use both. The code is in English, but nouns that are part of the ubiquitous business language are in Dutch. Translating business concepts into English would unnecessarily complicate understanding and communicating about functionality. Non-Dutch developers only need to pick up the names of a few concepts, just like remembering the names of your co-workers ;)
@dgoosens Also, I find that, in an agile environment, developing a ubiquitous language is hard enough without also introducing translations.
@youth very good point... thanks a lot
@dgoosens Mixed....
It highly depends on the customer. Some (german) customers have so german terminology that it is almost impossible to transfer that into english. Those words stay in german. Which then becomes a rather mixed business-language 
But when the well known abbreviation of a business-term is already longer than most english words.... (and unpronouncable anyhow. Think "RflEttÜAÜG" - https://de.wikipedia.org/wiki/Rindfleischetikettierungs%C3%BCberwachungsaufgaben%C3%BCbertragungsgesetz)
@heiglandreas
OMG...
I bet that word was really invented by a Java developer
@dgoosens I'd rather say by a Lawyer. But the overlap seems to be not small 
And Yes! Some class- or methodnames might exceed the 120 character line "limit" 
@dgoosens Same question, but encodings. Somehow non-UTF-8 encodings still manage to persist, and effed if I know why.
@pollita
Nice one…
The legacy project I work on is in win1252 in order to support French and German)
Previous devs chose this over UTF8 because « it takes less space in the database »
Doing my best not to think about murder
@dgoosens @pollita Given that the HTTP specs says that ISO-8891-1 should be interpreted as WIN1252 adds to the confusion.
And I'm not even talking about the mixup between encoding and charset...
Or MySQLs UTF-8 which in essence isn't UTF-8...
So yes:
*Use Unicode!*
(and support much more than english, french and german)
Whether with UTF-8 or UTF-16... who cares?
@dgoosens Have also had to have the extension of this conversation. American English vs British English. e.g. Is it "initialize" or "initialise"?
I think globally Pidgin English will be used… ie a simplified version of US English
As I did study translation and linguistics (and only accidentally became a dev) the subject of « code linguistics » does interest me a lot…
Planned to do some further research on this, as soon as I have some spare time, hopefully before retirement
@heiglandreas @dgoosens *Jumps out of an /American/ 1st floor window and lands safely on the ground less than a meter below.*
Muahahahahhaha *juns away laughing in en_US*
@pollita @heiglandreas @dgoosens I bet you start your arrays at 1 as well, don't you! Heathens!
@brunty @heiglandreas @dgoosens Almost universally, *sighs-and-screams-internally* yes.
@dgoosens this misses the right answer: mixed
There are technical termsy where English is the only choice ("get" for a getter is the trivial) but business terms might be local, as this is easy to map to business requirements and English terms may have a (slightly) different meaning. (Especially when legal requirements are involved)
In my past I did financial bilance analysis and after few iterations "getEigenkapitalrendite()" was the clear winner.
@johannes
Yes… you’re not first one to mention that and it definitely is the right approach in my opinion