4 ms·

No specifics about an algorithm (it's a DBMS system, there would be plenty to look for ;) But the title does not include any algorithm-requirements for beautifu

by sb 17y ago

No specifics about an algorithm (it's a DBMS system, there would be plenty to look for ;) But the title does not include any algorithm-requirements for beautiful code. ad Language: Of course its only natural, albeit unprofessional. I would expect anybody in a project to code using English, comments and identifiers--regardless of where the people actually come from. IMHO this is good coding practice, but probably you have different experiences.

foldr 17y ago
>I would expect anybody in a project to code using English Why? This might make sense for open source code at the moment, but if it's code internal to (say) a German organization, commenting in the native language of the coders is likely to be easier and lead to less confusion.
- sb 17y ago
  But what if you have multi-national staff, or at least expect to hire non-natives?
  - jacquesm 17y ago
    In this case the answer would then be "Learn German". Most multi-nationals have coding standards that mandate the use of English though. But you'd be surprised how many companies that grew to be multi-nationals from regional companies have tons of code documented and written in the native language.
    - sb 17y ago
      See, there is a catch 22: If they had used English in the first place, they wouldn't run into these problems later on ;)
      - foldr 17y ago
        That's not a catch 22, it's just a problem.
- mseebach 17y ago
  Because when you use English, you can write many statements that reads nicely - which you should aim for. if user.hasFoo() and company.isBar() then baz.play( jazz ) In German: if benutzer.hastFoo() and firma.istBar() then baz.spiel( jazz ) That's five language-switches in a single line. Much, much harder to read. (granted, only one if the language uses && and braces instead of and and then)
  - foldr 17y ago
    Does it really make it "much, much" harder to read? No proficient coder will be reading lines of code as English sentences, even if by some happy coincidence they happen to read that way. I don't think having a few keywords in a different language makes much difference. You might just as well say that the switch in languages makes the code easier to read, since it separates out keywords from variable names.
    - mseebach 17y ago
      > Does it really make it "much, much" harder to read? Yes. Maybe not harder, but more strenuous. > No proficient coder will be reading lines of code as English sentences In that case, I'm not a proficient coder. Neither was the inventors of the IF..THEN..ELSE and WHILE .. DO .. and DO .. WHILE .. statements. Or the guys who made the convention to use hasXX/isXX for boolean getters. Or LINQ. > I don't think having a few keywords in a different language makes much difference. I do, and I've coded and maintained a lot of code in both camps. And, we're not aiming for "much difference", we're aiming for "easier". > You might just as well say that the switch in languages makes the code easier to read, since it separates out keywords from variable names. Well, I don't think any proficient coder has any problem with that. We have syntax (and syntax highlighting) for that purpose.
      - foldr 17y ago
        >Yes. Maybe not harder, but more strenuous. So, what you actually mean to say here is "no"? Sorry, but I just don't see that having non-English identifiers makes it any harder (or more strenuous) to read. >In that case, I'm not a proficient coder. You certainly are not proficient if you attempt to read lines of code as English sentences because they happen to contain a few English words. >Well, I don't think any proficient coder has any problem with that. Nor will any proficient coder have a problem with a few English keywords.
- rimantas 17y ago
  Because we live in the global world and you can never be sure where will your code end up. I have had to deal with comments and DB schema which were neither in English nor in a language I speak, there was little pleasure in that. Having at least schema and indetifiers in English would have made everything much much easier. All programming languages I work with are more or less English based, so having schemas, comments, etc. in English is just a good fit and makes code easier to get should it land on the lap of some guy in another country.
  - jacquesm 17y ago
    That may not remain the case for long: http://www.chinesepython.org/cgi_bin/cgb.cgi/english/english.html http://www.chinesepython.org/cgi_bin/cgb.cgi/english/english...
  - foldr 17y ago
    >Because we live in the global world and you can never be sure where will your code end up Well you can't be sure of anything, but sometimes you know for more-or-less certain that English speakers aren't going to read the code.
jacquesm 17y ago
I think that greatly depends on the culture of the project and the language of those involved with it. Personally I code up all my stuff with identifiers, function names and comments in English. But I can't see why a German company writing code would be chastised for writing their code in German. I'd rather have them use German and do it properly than in broken English. Now in Germany most if not all programmers will be fluent (to some degree) in English, but in plenty of other countries that is not the case. Being able to program should not come with an automatic requirement to be fluent in English as well. Obviously there are issues with character sets when writing comments, plenty of language implementations wouldn't know what to do if you threw utf-8 at them, but I think that any modern implementation should allow for identifier names and comments to be in any language. Why should the English speaking world get a free pass here, and everybody else be at a disadvantage ?
- sb 17y ago
  "Being able to program should not come with an automatic requirement to be fluent in English as well." It doesn't, and I merely said that I think it's good practice to do so. (For various reasons, e.g. a multi-national team, possible maintenance and re-engineering scenarios where it might be helpful to use standardized abbreviations, etc.) I have personally worked on a reengineering project that used German identifiers because of a very specific ERP system--it was ultimately decided not to use English identifiers because the translations would be too cumbersome. (This was a small company, what I am trying to say is a company like SAP [big] code a DBMS [inherently English domain] using German comments makes no sense to me...)
  - jacquesm 17y ago
    I think you have a 'neutrality of viewpoint' issue. SAP = BIG = not a reason to do stuff in english DBMS = inherently English domain because people don't use their own language, that's self-referential Using German comments makes perfect sense, SAP being a German company. It works like this: a company starts out making a product for their local market, they get successful and branch out, and then a large amount of time later their code gets opened up to programmers not familiar with the native language. Now, if the company were American, nobody would have a problem with dealing with identifiers and comments in what is for them a foreign language, say English. But I really don't see why an American programmer would have a bigger problem dealing with identifiers and comments in German than vv. Computer programming is not an exclusively English domain, and if to you code with identifiers and comments in a foreign language is hard to read then you have a bit of a hint how much effort the rest of the world has to make in order to make that step. The fact that English got there 'first' is already enough of a head start, that shouldn't mean it becomes mandatory. Something similar happens in the world of scientific publishing, where basically publishing in Spanish, Greek or Dutch is equal to not publishing at all. An algorithm with Dutch, German or Swahili identifiers and comments is exactly equivalent to one in English. Probably if you spent enough time you could figure out what the comments meant even if you didn't speak the language. Not that that would be very productive, and that's why most larger companies (and definitely multinationals) standardize on English. You should be happy that's the case, but it is by no means a requirement or a sign of not being professional. If 90% of the team is German I'm all for them coding in German.

by sb 17y ago

foldr 17y ago

>I would expect anybody in a project to code using English Why? This might make sense for open source code at the moment, but if it's code internal to (say) a German organization, commenting in the native language of the coders is likely to be easier and lead to less confusion.

sb 17y ago
But what if you have multi-national staff, or at least expect to hire non-natives?
- jacquesm 17y ago
  In this case the answer would then be "Learn German". Most multi-nationals have coding standards that mandate the use of English though. But you'd be surprised how many companies that grew to be multi-nationals from regional companies have tons of code documented and written in the native language.
  - sb 17y ago
    See, there is a catch 22: If they had used English in the first place, they wouldn't run into these problems later on ;)
    - foldr 17y ago
      That's not a catch 22, it's just a problem.
mseebach 17y ago
Because when you use English, you can write many statements that reads nicely - which you should aim for. if user.hasFoo() and company.isBar() then baz.play( jazz ) In German: if benutzer.hastFoo() and firma.istBar() then baz.spiel( jazz ) That's five language-switches in a single line. Much, much harder to read. (granted, only one if the language uses && and braces instead of and and then)
- foldr 17y ago
  Does it really make it "much, much" harder to read? No proficient coder will be reading lines of code as English sentences, even if by some happy coincidence they happen to read that way. I don't think having a few keywords in a different language makes much difference. You might just as well say that the switch in languages makes the code easier to read, since it separates out keywords from variable names.
  - mseebach 17y ago
    > Does it really make it "much, much" harder to read? Yes. Maybe not harder, but more strenuous. > No proficient coder will be reading lines of code as English sentences In that case, I'm not a proficient coder. Neither was the inventors of the IF..THEN..ELSE and WHILE .. DO .. and DO .. WHILE .. statements. Or the guys who made the convention to use hasXX/isXX for boolean getters. Or LINQ. > I don't think having a few keywords in a different language makes much difference. I do, and I've coded and maintained a lot of code in both camps. And, we're not aiming for "much difference", we're aiming for "easier". > You might just as well say that the switch in languages makes the code easier to read, since it separates out keywords from variable names. Well, I don't think any proficient coder has any problem with that. We have syntax (and syntax highlighting) for that purpose.
    - foldr 17y ago
      >Yes. Maybe not harder, but more strenuous. So, what you actually mean to say here is "no"? Sorry, but I just don't see that having non-English identifiers makes it any harder (or more strenuous) to read. >In that case, I'm not a proficient coder. You certainly are not proficient if you attempt to read lines of code as English sentences because they happen to contain a few English words. >Well, I don't think any proficient coder has any problem with that. Nor will any proficient coder have a problem with a few English keywords.
rimantas 17y ago
Because we live in the global world and you can never be sure where will your code end up. I have had to deal with comments and DB schema which were neither in English nor in a language I speak, there was little pleasure in that. Having at least schema and indetifiers in English would have made everything much much easier. All programming languages I work with are more or less English based, so having schemas, comments, etc. in English is just a good fit and makes code easier to get should it land on the lap of some guy in another country.
- jacquesm 17y ago
  That may not remain the case for long: http://www.chinesepython.org/cgi_bin/cgb.cgi/english/english.html http://www.chinesepython.org/cgi_bin/cgb.cgi/english/english...
- foldr 17y ago
  >Because we live in the global world and you can never be sure where will your code end up Well you can't be sure of anything, but sometimes you know for more-or-less certain that English speakers aren't going to read the code.

jacquesm 17y ago

I think that greatly depends on the culture of the project and the language of those involved with it. Personally I code up all my stuff with identifiers, function names and comments in English. But I can't see why a German company writing code would be chastised for writing their code in German. I'd rather have them use German and do it properly than in broken English. Now in Germany most if not all programmers will be fluent (to some degree) in English, but in plenty of other countries that is not the case. Being able to program should not come with an automatic requirement to be fluent in English as well. Obviously there are issues with character sets when writing comments, plenty of language implementations wouldn't know what to do if you threw utf-8 at them, but I think that any modern implementation should allow for identifier names and comments to be in any language. Why should the English speaking world get a free pass here, and everybody else be at a disadvantage ?

sb 17y ago
"Being able to program should not come with an automatic requirement to be fluent in English as well." It doesn't, and I merely said that I think it's good practice to do so. (For various reasons, e.g. a multi-national team, possible maintenance and re-engineering scenarios where it might be helpful to use standardized abbreviations, etc.) I have personally worked on a reengineering project that used German identifiers because of a very specific ERP system--it was ultimately decided not to use English identifiers because the translations would be too cumbersome. (This was a small company, what I am trying to say is a company like SAP [big] code a DBMS [inherently English domain] using German comments makes no sense to me...)
- jacquesm 17y ago
  I think you have a 'neutrality of viewpoint' issue. SAP = BIG = not a reason to do stuff in english DBMS = inherently English domain because people don't use their own language, that's self-referential Using German comments makes perfect sense, SAP being a German company. It works like this: a company starts out making a product for their local market, they get successful and branch out, and then a large amount of time later their code gets opened up to programmers not familiar with the native language. Now, if the company were American, nobody would have a problem with dealing with identifiers and comments in what is for them a foreign language, say English. But I really don't see why an American programmer would have a bigger problem dealing with identifiers and comments in German than vv. Computer programming is not an exclusively English domain, and if to you code with identifiers and comments in a foreign language is hard to read then you have a bit of a hint how much effort the rest of the world has to make in order to make that step. The fact that English got there 'first' is already enough of a head start, that shouldn't mean it becomes mandatory. Something similar happens in the world of scientific publishing, where basically publishing in Spanish, Greek or Dutch is equal to not publishing at all. An algorithm with Dutch, German or Swahili identifiers and comments is exactly equivalent to one in English. Probably if you spent enough time you could figure out what the comments meant even if you didn't speak the language. Not that that would be very productive, and that's why most larger companies (and definitely multinationals) standardize on English. You should be happy that's the case, but it is by no means a requirement or a sign of not being professional. If 90% of the team is German I'm all for them coding in German.