Tag Info

New answers tagged

3

From what I have both read and experienced, it is not a good practice to have more than one single step in initialization of an object. This is not good because You need to babysit all such objects, so that the required initialization steps are completed before the objects are used You would have to expect anyone using your code to also properly babysit ...


2

The rule I use quite often is to remove the plural and the subject from the original property name, then add "to". In your example, I would probably end up with: public class Box { public long BoxId { get; set; } public virtual Process InputTo { get; set; } /* ugly name */ public virtual Process OutputTo { get; set; } /* ugly name */ } ...


1

Ask yourself this question: "if I do this, does it make the program easier to understand?". Outside of functionality, one of your main goals when writing code should be clarity. Code is read many, many times more than it is written so it should be as easy to understand as possible. Choose patterns that aid in readability.


2

Look no further than C++'s STL: std::map std::map is a sorted associative container that contains key-value pairs with unique keys. Keys are sorted by using the comparison function Compare. Search, removal, and insertion operations have logarithmic complexity. Maps are usually implemented as red-black trees. std::unordered_map ...


2

Since other (Java) implementations of Collections describe their implementation, sometimes to great detail (e.g. CopyOnWriteArrayList) I would say yes, naming after the implementation is fine, and is expected. Unlike @supercat, I think this detailed naming is a good thing, as, unfortunately, at some point, somebody actually has to pick a specific ...


5

A class identifier should reflect things that outside users of that class identifier are likely to care about. Because different users are likely to care about different things, it will generally not be possible to find a name with the "perfect" level of descriptiveness for all usage scenarios. Note that there is a common pattern of List foo<Bar> = ...


1

I've always thought this is something that's done mostly because it amuses people. People are conditioned by the media to attach value to skulking around in the dark vs. operating in the light of day. At age 5 we have "Special Agent Oso"; at age 15 it's James Bond. Secrecy lends an air of importance to people's otherwise mundane activities (e.g. programming ...


1

The first reason is that it can be short and memorable. If you think about how many times you are going to say or write the name of the project, you save a substantial amount of time if there is a brief name that everyone knows and understands. The second reason is that it builds camaraderie. If the team gets to pick the name, that can pick one that they ...


3

This may be related to high context or low context culture. Every company, organization, or team has its own culture. High or low context culture means how much information a culture likes to relate explicitly, and how much people are expected to take from context. Naming all the services with names from cultural references does provide some flexibility, ...


1

One reason for codenames is obfuscation. If you make the name of a project meaningless, then you can talk about it in public without anyone else understanding what you are discussing. Similarly, if you give your servers meaningless names, then nobody except the authorised users will have any idea what's on them.


1

there may well be a system you just don't know. One company I worked for used names of Nobel prize winners for all their servers. Different Nobel prizes indicated different categories of servers. Test servers might be named after mathematics winners, database servers after literature winners, mail servers after medicine winners, etc. etc. To someone not ...


2

The important question is: what is descriptive? The other answers have done a great job illustrating what is not descriptive. Let's establish that descriptiveness comes from calling things by their role, their purpose. By what they do. For example, it's pretty clear, what a "cutter" does. Now it could be an ax, a laser or a knife. It doesn't matter so much. ...


8

There are 3 reasons, in my experience: When you have to name lots of similar things it can be hard to find unique descriptive names for all of them. People need a short unique way of referring to it, and we're better at using names than we are at using numbers (unless the number is very short). When you give it a name, it tends to take on a personality ...


8

Naming things by their properties is a fundamentally bad idea. The reason is that properties are, by definition, changeable phenomena, while the identity of a thing stays the same even if properties are changed. Someone decides that the file server should be migrated to Linux? If its name is "Apollo", that's not a problem. If the name referenced "windows", ...


22

We don't reference people by their characteristics as it takes all day to list them in enough detail to be unambiguous and the characteristics can change. What if they get a haircut? Instead we give them names. Also, people are better at remembering words than streams of random symbols. Disclaimer: This is going to contain some opinion and anecdotal ...


5

Descriptive naming is hardâ„¢, it's much easier if you already have a theme which automatically comes with a list of words you can use. When you have multiple of the same object naming them foo1.6, foo1.2, etc. quickly gets confusing/prone to mistakes. For example when you need to run your test on Virgo then you will quickly notice the mistake if you are ...


0

You could use Nullable<T> (borrowing the name from .NET; that's its standard library's equivalent of Guava's Optional<T>), and since there's the @Nullable / @NonNull annotation pair in Java, you could name the other one NonNull<T> to kind of align your naming with the convention. On a side note, I have to say that the whole idea sounds a ...



Top 50 recent answers are included