|
Sean McPoland wrote: Watched it again last night,
A sobering thought[^]
Psychosis at 10
Film at 11
Those who do not remember the past, are doomed to repeat it.
Those who do not remember the past, cannot build upon it.
|
|
|
|
|
Ain't that the truth,
I 'know' it was made in 1975, and I watched it in 1975, but when you put it like that,
It's another dimension!
|
|
|
|
|
ProjectX for the primary namespace and then ProjectX.Whatever, etc., maybe ProjectX.Model, ProjectX.DAL, ProjectX.Common where ProjectX is the name of the project. And sometimes it is.
|
|
|
|
|
namespace RavSoft.MyApp {
}/ravi
|
|
|
|
|
I follow the Java standard for package names, so everything is under com.vilmos. Actually that's a lie, it's mostly com.lexa, but that's because there is a master project called Lexa.
veni bibi saltavi
|
|
|
|
|
Bleh, I hate that convention... Why, when I'm searching through my endless list of dependencies (Don't get me started...), should I have to remember whether it's a com, net, or org?
.NET just does it better (Like so many things)... Anything in the basic framework is System., anything Windows-specific is Microsoft., and anything else is CompanyName.* or LibraryName.*
|
|
|
|
|
Nagy Vilmos wrote: there is a master project called Lexa
The #1 Dutch dating site? 
|
|
|
|
|
I use the alphabet.
a.b.c etc...
j/k
CompanyName.SoftwareProjectName.VisualStudioProjectName (ACME.RoadRunner.DAL) or something like that.
or
SoftwareProjectName.VisualStudioProjectName (RoadRunner.DAL) or something like that.
|
|
|
|
|
Slacker007 wrote: ACME.RoadRunner
beep beep
What we got here is a failure to communicate
|
|
|
|
|
|
Slacker007 wrote: ACME.RoadRunner
Well, at least that ACME stuff crashed about as often as Visual Studio  
|
|
|
|
|
PIEBALD
PIEBALD.Lib
PIEBALD.Data
PIEBALD.Type
etc.
|
|
|
|
|
|
Me too. If I get the chance.
As a contractor I either have to be "whiter than white" (which is why I follow the M$ way whenever possible) or have to adhere to local convention, regardless of how silly it might be 
|
|
|
|
|
"CONSIDER using plural namespace names where appropriate."
Never pluralize.
|
|
|
|
|
|
That's a rule for database tables 
|
|
|
|
|
|
And it's wrong, well, at least when it comes to standards.
The ISO standard says Pluralize.
|
|
|
|
|
|
The Joint Technical Committee (ISO/IEC JTC 1, Information technology, Subcommittee SC 32) that develops the SQL Standard has specified that one should follow ISO/IEC_11179[^] for naming. Which states Singular for Columns and Plural for Tables.
The point of following standards, even if you don't like the aesthetics, is (amongst others) to minimize ambiguity.
The concept behind it is as simple as it gets. A row is singular. A collection of rows is plural.
So reason one in your link is just conceptually wrong. Yes, an applebag can contain apples but you don't name the bag "Apple", you name it "Bag".
The content that you search are Apples.
But I guess that's why you see so many tables following the pattern "tblCustomer". 
And the rest is just opinions.
As far as I'm concerned you can do as you want. But if you choose one way, you should stick to it. That's much more important
|
|
|
|
|
MSDN wrote: X DO NOT use the same name for a namespace and a type in that namespace.
HATE it when that happens
|
|
|
|
|
Since a solution can contain projects directly related to an app, as well as commonly shared projects, I use the following. Note that not all are needed:
** For the app itself
Company.Project.Core
Company.Project.DAL
Company.Project.BL
Company.Project.Entities
Company.Project.Shared
Company.Project.Tools
Company.Project.UI.WPF.Controls
Company.Project.UI.WPF.Desktop
Company.Project.UI.WPF.Phone
Company.Project.UI.WPF.Tablet
Company.Project.UI.Web.MVC
** Projects shared by many apps
Company.WPF.Controls
Company.WPF.Entities
Company.WPF.Themes
Company.WPF.Utilites
If it's not broken, fix it until it is
|
|
|
|
|
Since the source code for our projects is proprietary, we omit the company identification from the namespace name.
For .NET, our namespaces are Assembly{.Package} where Assembly is the assembly name and the {.Package} suffix is only used where an assembly contains more than one significant body of code.
For C++ we usually just use the global namespace. I did have one C++ project where a combination of namespace's and a templated base class really improved the readability of a pile of related classes.
Software Zen: delete this;
|
|
|
|
|
Last time I needed a namespace, I happened to play a game. My new commander had just arrived at my base and yelled "Forces of chaos, bow to me!" So my new namespace became FoC, which is very accurate for most software projects.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
If software development were a circus, we would all be the clowns.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
