Namespaces naming policy (English vs. native language)
-
I'm early in the process of designing a new application... to make it shorter as possible, what naming convention or policy do you prefer for your namespaces (and classes and other)? In my last company we were somewhat "xenophobic" and mostly used Croatian words, while in company where I work now we use English almost exclusively. I've been in both camps and I cannot decide to where should I turn. What is your experience with naming in your native tongue?
-
I'm early in the process of designing a new application... to make it shorter as possible, what naming convention or policy do you prefer for your namespaces (and classes and other)? In my last company we were somewhat "xenophobic" and mostly used Croatian words, while in company where I work now we use English almost exclusively. I've been in both camps and I cannot decide to where should I turn. What is your experience with naming in your native tongue?
Well, I'm English so it makes sense for me to do this in English. However, why not follow Microsoft's naming recommendations for namespaces? CompanyName.TechnologyName[.Feature][.Design]
Deja View - the feeling that you've seen this post before.
-
I'm early in the process of designing a new application... to make it shorter as possible, what naming convention or policy do you prefer for your namespaces (and classes and other)? In my last company we were somewhat "xenophobic" and mostly used Croatian words, while in company where I work now we use English almost exclusively. I've been in both camps and I cannot decide to where should I turn. What is your experience with naming in your native tongue?
Hi, I would suggest you use the same language for code as you do for comments. So if you plan on commenting in English, choose English namespaces, classes, methods, etc. And if you comment in Croatian, use Croatian identifiers for everything you create (of course the .NET Frameword classes will remain English, as in File.Open). Personally I program in English exclusively, although it isn't my native language. And I tend to buy technical books in English, not in Dutch/French/German/whatever, since that only generates delays, confusion, less choice, and more errors. :)
Luc Pattyn [Forum Guidelines] [My Articles]
This month's tips: - before you ask a question here, search CodeProject, then Google; - the quality and detail of your question reflects on the effectiveness of the help you are likely to get; - use PRE tags to preserve formatting when showing multi-line code snippets.
-
Well, I'm English so it makes sense for me to do this in English. However, why not follow Microsoft's naming recommendations for namespaces? CompanyName.TechnologyName[.Feature][.Design]
Deja View - the feeling that you've seen this post before.
I would usually do that, but this my side project. To me it looks too vain if you would make something like this Deka.UI.Web . I still have some time to think about it.
-
I would usually do that, but this my side project. To me it looks too vain if you would make something like this Deka.UI.Web . I still have some time to think about it.
Oshtri Deka wrote:
I would usually do that, but this my side project. To me it looks too vain if you would make something like this Deka.UI.Web .
It's not vanity. It's there to prevent namespace collisions. Suppose you have two companies producing a project called Widget, then you would have Company1.Widget and Company2.Widget. In this way, the namespaces and classes won't collide.
Deja View - the feeling that you've seen this post before.
-
Oshtri Deka wrote:
I would usually do that, but this my side project. To me it looks too vain if you would make something like this Deka.UI.Web .
It's not vanity. It's there to prevent namespace collisions. Suppose you have two companies producing a project called Widget, then you would have Company1.Widget and Company2.Widget. In this way, the namespaces and classes won't collide.
Deja View - the feeling that you've seen this post before.
That's obvious choice when you are working for a company, but this is a hobby project. I'll put my nickname as part of basic namespace, vain or not... and people will know of whom they should make fun, if it ends as a pile of crappy code. :-D I am paying too much attention to some details.
-
That's obvious choice when you are working for a company, but this is a hobby project. I'll put my nickname as part of basic namespace, vain or not... and people will know of whom they should make fun, if it ends as a pile of crappy code. :-D I am paying too much attention to some details.
Oshtri Deka wrote:
That's obvious choice when you are working for a company, but this is a hobby project.
Still unimportant. If your code has the potential for any form of namespace collision then this is the obvious way to avoid it.
Oshtri Deka wrote:
I'll put my nickname as part of basic namespace
That's fine unless your nickname is Microsoft.
Deja View - the feeling that you've seen this post before.
-
That's obvious choice when you are working for a company, but this is a hobby project. I'll put my nickname as part of basic namespace, vain or not... and people will know of whom they should make fun, if it ends as a pile of crappy code. :-D I am paying too much attention to some details.
Oshtri Deka wrote:
I am paying too much attention to some details.
Welcome to the analysis paralysis club. I'm a founder member.
-
Oshtri Deka wrote:
I am paying too much attention to some details.
Welcome to the analysis paralysis club. I'm a founder member.
:laugh: Perhaps we should organize a support group.