Related
It seems like people who would never dare cut and paste code have no problem specifying the type of something over and over and over. Why isn't it emphasized as a good practice that type information should be declared once and only once so as to cause as little ripple effect as possible throughout the source code if the type of something is modified? For example, using pseudocode that borrows from C# and D:
MyClass<MyGenericArg> foo = new MyClass<MyGenericArg>(ctorArg);
void fun(MyClass<MyGenericArg> arg) {
gun(arg);
}
void gun(MyClass<MyGenericArg> arg) {
// do stuff.
}
Vs.
var foo = new MyClass<MyGenericArg>(ctorArg);
void fun(T)(T arg) {
gun(arg);
}
void gun(T)(T arg) {
// do stuff.
}
It seems like the second one is a lot less brittle if you change the name of MyClass, or change the type of MyGenericArg, or otherwise decide to change the type of foo.
I don't think you're going to find a lot of disagreement with your argument that the latter example is "better" for the programmer. A lot of language design features are there because they're better for the compiler implementer!
See Scala for one reification of your idea.
Other languages (such as the ML family) take type inference much further, and create a whole style of programming where the type is enormously important, much more so than in the C-like languages. (See The Little MLer for a gentle introduction.)
It isn't considered a bad thing at all. In fact, C# maintainers are already moving a bit towards reducing the tiring boilerplate with the var keyword, where
MyContainer<MyType> cont = new MyContainer<MyType>();
is exactly equivalent to
var cont = new MyContainer<MyType>();
Although you will see many people who will argue against var usage, which kind of shows that many people is not familiar with strong typed languages with type inference; type inference is mistaken for dynamic/soft typing.
Repetition may lead to more readable code, and sometimes may be required in the general case. I've always seen the focus of DRY being more about duplicating logic than repeating literal text. Technically, you can eliminate 'var' and 'void' from your bottom code as well. Not to mention you indicate scope with indentation, why repeat yourself with braces?
Repetition can also have practical benefits: parsing by a program is easier by keeping the 'void', for example.
(However, I still strongly agree with you on prefering "var name = new Type()" over "Type name = new Type()".)
It's a bad thing. This very topic was mentioned in Google's Go language Techtalk.
Albert Einstein said, "Everything should be made as simple as possible, but not one bit simpler."
Your complaint makes no sense in the case of a dynamically typed language, so you must intend this to refer to statically typed languages. In that case, your replacement example implicitly uses Generics (aka Template Classes), which means that any time that fun or gun is used, a new definition based upon the type of the argument. That could result in dozens of extra methods, regardless of the intent of the programmer. In particular, you're throwing away the benefit of compiler-checked type-safety for a runtime error.
If your goal was to simply pass through the argument without checking its type, then the correct type would be Object not T.
Type declarations are intended to make the programmer's life simpler, by catching errors at compile-time, instead of failing at runtime. If you have an overly complex type definition, then you probably don't understand your data. In your example, I would have suggested adding fun and gun to MyClass, instead of defining them separately. If fun and gun don't apply to all possible template types, then they should be defined in an explicit subclass, not as separate functions that take a templated class argument.
Generics exist as a way to wrap behavior around more specific objects. List, Queue, Stack, these are fine reasons for Generics, but at the end of the day, the only thing you should be doing with a bare Generic is creating an instance of it, and calling methods on it. If you really feel the need to do more than that with a Generic, then you probably need to embed your Generic class as an instance object in a wrapper class, one that defines the behaviors you need. You do this for the same reason that you embed primitives into a class: because by themselves, numbers and strings do not convey semantic information about their contents.
Example:
What semantic information does List convey? Just that you're working with multiple triples of integers. On the other hand, List, where a color has 3 integers (red, blue, green) with bounded values (0-255) conveys the intent that you're working with multiple Colors, but provides no hint as to whether the List is ordered, allows duplicates, or any other information about the Colors. Finally a Palette can add those semantics for you: a Palette has a name, contains multiple Colors, but no duplicates, and order isn't important.
This has gotten a bit far afield from the original question, but what it means to me is that DRY (Don't Repeat Yourself) means specifying information once, but that specification should be as precise as is necessary.
Edit: There appears to be at least two valid reasons why Smalltalkers do this (readability during message chaining and scoping issues) but perhaps the question can remain open longer to address general usage.
Original: For reasons I've long forgotten, I never use articles in my variable names. For instance:
aPerson, theCar, anObject
I guess I feel like articles dirty up the names with meaningless information. When I'd see a coworker's code using this convention, my blood pressure would tick up oh-so-slightly.
Recently I've started learning Smalltalk, mostly because I want to learn the language that Martin Fowler, Kent Beck, and so many other greats grew up on and loved.
I noticed, however, that Smalltalkers appear to widely use indefinite articles (a, an) in their variable names. A good example would be in the following Setter method:
name: aName address: anAddress.
self name: aName.
self address: anAddress
This has caused me to reconsider my position. If a community as greatly respected and influential as Smalltalkers has widely adopted articles in variable naming, maybe there's a good reason for it.
Do you use it? Why or why not?
This naming convention is one of the patterns in Kent Beck's book Smalltalk Best Practice Patterns. IMHO this book is a must-have even for non-smalltalkers, as it really helps naming things and writing self-documenting code. Plus it's probably one of the few pattern langages to exhibit Alexander's quality without a name.
Another good book on code patterns is Smalltalk with Style, which is available as a free PDF.
Generally, the convention is that instance variables and accessors use the bare noun, and parameters use the indefinite article plus either a role or a type, or a combination. Temporary variables can use bare nouns because they rarely duplicate the instance variable; alternatively, it's quite frequent to name them with more precision than just an indefinite article, in order to indicate their role in the control flow: eachFoo, nextFoo, randomChild...
It is in common use in Smalltalk as a typeless language because it hints the type of an argument in method call. The article itself signals that you are dealing with an instance of some object of specified class.
But remember that in Smalltalk the methods look differently, we use so called keyword messages and it this case the articles actually help the readability:
anAddressBook add: aPerson fromTownNamed: aString
I think I just found an answer. As Konrad Rudolph said, they use this convention because of a technical reason:
...this means it [method variable] cannot duplicate the name of an instance variable, a temporary variable defined in the interface, or another temporary variable.
-IBM Smalltalk Tutorial
Basically a local method variable cannot be named the same as an object/class variable. Coming from Java, I assumed a method's variables would be locally scoped, and you'd access the instance variables using something like:
self address
I still need to learn more about the method/local scoping in Smalltalk, but it appears they have no other choice; they must use a different variable name than the instance one, so anAddress is probably the simplest approach. Using just address results in:
Name is already defined ->address
if you have an instance variable address defined already...
I always felt the articles dirtied up the names with meaningless information.
Exactly. And this is all the reason necessary to drop articles: they clutter the code needlessly and provide no extra information.
I don’t know Smalltalk and can't talk about the reasons for “their” conventions but everywhere else, the above holds. There might be a simple technical reason behind the Smalltalk convention (such as ALL_CAPS in Ruby, which is a constant not only by convention but because of the language semantics).
I wobble back and forth on using this. I think that it depends on the ratio of C++ to Objective C in my projects at any given time. As for the basis and reasoning, Smalltalk popularized the notion of objects being "things". I think that it was Yourdon and Coad that strongly pushed describing classes in the first person. In Python it would be something like the following snippet. I really wish that I could remember enough SmallTalk to put together a "proper" example.
class Rectangle:
"""I am a rectangle. In other words, I am a polygon
of four sides and 90 degree vertices."""
def __init__(self, aPoint, anotherPoint):
"""Call me to create a new rectangle with the opposite
vertices defined by aPoint and anotherPoint."""
self.myFirstCorner = aPoint
self.myOtherCorner = anotherPoint
Overall, it is a conversational approach to program readability. Using articles in variable names was just one portion of the entire idiom. There was also an idiom surrounding the naming of parameters and message selectors IIRC. Something like:
aRect <- [Rectangle createFromPoint: startPoint
toPoint: otherPoint]
It was just another passing fad that still pops up every so often. Lately I have been noticing that member names like myHostName are popping up in C++ code as an alternative to m_hostName. I'm becoming more enamored with this usage which I think hearkens back to SmallTalk's idioms a little.
Never used, maybe because in my main language there are not any articles :P
Anyway i think that as long as variable's name is meaningful it's not important if there are articles or not, it's up to the coder's own preference.
Nope. I feel it is waste of characters space and erodes the readability of your code. I might use variations of the noun, for example Person vs People depending on the context. For example
ArrayList People = new ArrayList();
Person newPerson = new Person();
People.add(newPerson);
No I do not. I don't feel like it adds anything to the readability or maintainability of my code base and it does not distinguish the variable for me in any way.
The other downside is if you encourage articles in variable names, it's just a matter of time before someone does this in your code base.
var person = new Person();
var aPerson = GetSomeOtherPerson();
Where I work, the standard is to prefix all instance fields with "the-", local variables with "my-" and method parameters with "a-". I believe this came about because many developers were using text editors like vi instead of IDE's that can display different colors per scope.
In Java, I'd have to say I prefer it over writing setters where you dereference this.
Compare
public void setName(String name) {
this.name = name;
}
versus
public void setName(String aName) {
theName = aName;
}
The most important thing is to have a standard and for everyone to adhere to it.
No doubt, it's essential for understanding code to give member variables a prefix so that they can easily be distinguished from "normal" variables.
But what kind of prefix do you use?
I have been working on projects where we used m_ as prefix, on other projects we used an underscore only (which I personally don't like, because an underscore only is not demonstrative enough).
On another project we used a long prefix form, that also included the variable type. mul_ for example is the prefix of a member variable of type unsigned long.
Now let me know what kind of prefix you use (and please give a reason for it).
EDIT: Most of you seem to code without special prefixes for member variables! Does this depend on the language? From my experience, C++ code tends to use an underscore or m_ as a prefix for member variables. What about other languages?
No doubt, it's essential for understanding code to give member variables a prefix so that they can easily be distinguished from "normal" variables.
I dispute this claim. It's not the least bit necessary if you have half-decent syntax highlighting. A good IDE can let you write your code in readable English, and can show you the type and scope of a symbol other ways. Eclipse does a good job by highlighting declarations and uses of a symbol when the insertion point is on one of them.
Edit, thanks slim: A good syntax highlighter like Eclipse will also let you use bold or italic text, or change fonts altogether. For instance, I like italics for static things.
Another edit: Think of it this way; the type and scope of a variable are secondary information. It should be available and easy to find out, but not shouted at you. If you use prefixes like m_ or types like LPCSTR, that becomes noise, when you just want to read the primary information – the intent of the code.
Third edit: This applies regardless of language.
I do not use any prefix at all. If I run into danger of mixing up local variables or method parameters with class members, then either the method or the class is too long and benefits from splitting up.
This (arguably) not only makes the code more readable and somewhat "fluent", but most importantly encourages well structured classes and methods. In the end, it thus boils down to a completely different issue than the prefix or no-prefix dillema.
UPDATE: well, taste and preferences change, don't they.. I now use underscore as the prefix for member variables as it has proven to be beneficial in recognizing local and member variables in the long run. Especially new team members sometimes have hard time when the two are not easily recognizable.
None. I used to use underscore, but was talked out of it on a project where the others didn't like it, and haven't missed it. A decent IDE or a decent memory will tell you what's a member variable and what isn't. One of the developers on our project insists on putting "this." in front of every member variable, and we humour him when we're working on areas of code that are nominally "his".
Underscore only.
In my case, I use it because that's what the coding standards document says at my workplace. However, I cannot see the point of adding m_ or some horrible Hungarian thing at the beginning of the variable. The minimalist 'underscore only' keeps it readable.
It's more important to be consistent than anything, so pick something you and your teammates can agree upon and stick with it. And if the language you're coding in has a convention, you should try to stick to it. Nothing's more confusing than a code base that follows a prefixing rule inconsistently.
For c++, there's another reason to prefer m_ over _ besides the fact that _ sometimes prefixes compiler keywords. The m stands for member variable. This also gives you the ability disambiguate between locals and the other classes of variables, s_ for static and g_ for global (but of course don't use globals).
As for the comments that the IDE will always take care of you, is the IDE really the only way that you're looking at your code? Does your diff tool have the same level of quality for syntax hilighting as your IDE? What about your source control revision history tool? Do you never even cat a source file to the command line? Modern IDE's are fantastic efficiency tools, but code should be easy to read regardless of the context you're reading it in.
I prefer using this keyword.
That means this.data or this->data instead of some community-dependent naming.
Because:
with nowadays IDEs typing this. popups intellinsense
its obvious to everyone without knowing defined naming
BTW prefixing variables with letters to denote their type is outdated with good IDEs and reminds me of this Joel's article
We use m_ and then a slightly modified Simonyi notation, just like Rob says in a previous response. So, prefixing seems useful and m_ is not too intrusive and easily searched upon.
Why notation at all? And why not just follow (for .NET) the Microsoft notation recommendations which rely upon casing of names?
Latter question first: as pointed out, VB.NET is indifferent to casing. So are databases and (especially) DBAs. When I have to keep straight customerID and CustomerID (in, say, C#), it makes my brain hurt. So casing is a form of notation, but not a very effective one.
Prefix notation has value in several ways:
Increases the human comprehension of code without using the IDE. As in code review -- which I still find easiest to do on paper initially.
Ever write T-SQL or other RDBMS stored procs? Using prefix notation on database column names is REALLY helpful, especially for those of us who like using text editors for this sort of stuff.
Maybe in short, prefixing as a form of notation is useful because there are still development environments where smart IDEs are not available. Think about the IDE (a software tool) as allowing us some shortcuts (like intellisense typing), but not comprising the whole development environment.
An IDE is an Integrated Development Environment in the same way that a car is a Transportation Network: just one part of a larger system. I don't want to follow a "car" convention like staying on marked roads, when sometimes, its faster just to walk through a vacant lot. Relying on the IDE to track variable typing would be like needing the car's GPS to walk through the vacant lot. Better to have the knowledge (awkward though it may be to have "m_intCustomerID") in a portable form than to run back to the car for every small change of course.
That said, the m_ convention or the "this" convention are both readable. We like m_ because it is easily searched and still allows the variable typing to follow it. Agreed that a plain underscore is used by too many other framework code activities.
Using C#, I've moved from the 'm_'-prefix to just an underscore, since 'm_' is an heritage from C++.
The official Microsoft Guidelines tells you not to use any prefixes, and to use camel-case on private members and pascal-case on public members. The problem is that this collides with another guideline from the same source, which states that you should make all code compatible with all languages used in .NET. For instance, VB.NET doesn't make a difference between casings.
So just an underscore for me. This also makes it easy to access through IntelliSense, and external code only calling public members don't have to see the visually messy underscores.
Update: I don't think the C# "this."-prefix helps out the "Me." in VB, which will still see "Me.age" the same as "Me.Age".
It depends on which framework I'm using! If I'm writing MFC code then I use m_ and Hungarian notation. For other stuff (which tends to be STL/Boost) then I add an underscore suffix to all member variables and I don't bother with Hungarian notation.
MFC Class
class CFoo
{
private:
int m_nAge;
CString m_strAddress;
public:
int GetAge() const { return m_nAge; }
void SetAge(int n) { m_nAge = n; }
CString GetAddress() const { return m_strAddress;
void SetAddress(LPCTSTR lpsz) { m_strAddress = lpsz; }
};
STL Class
class foo
{
private:
int age_;
std::string address_;
public:
int age() const { return age_; }
void age(int a) { age_ = a; }
std::string address() const { return address_; }
void address(const std::string& str) { address_ = str; }
};
Now this may seem a bit odd - two different styles - but it works for me, and writing a lot of MFC code that doesn't use the same style as MFC itself just looks ugly.
I prefix member variables with 'm' and parameters (in the function) with 'p'. So code will look like:
class SomeClass {
private int mCount;
...
private void SomeFunction(string pVarName) {...}
}
I find that this quickly tells you the basic scope of any variable - if no prefix, then it's a local. Also, when reading a function you don't need to think about what's being passed in and what's just a local variable.
It really depends on the language.
I'm a C++ guy, and prefixing everything with underscore is a bit tricky. The language reserves stuff that begins with underscore for the implementation in some instances (depending on scope). There's also special treatment for double underscore, or underscore following by a capital letter. So I say just avoid that mess and simply choose some other prefix. 'm' is ok IMO. 'm_' is a bit much, but not terrible either. A matter of taste really.
But watch out for those _leadingUnderscores. You'll be surprised how many compiler and library internals are so named, and there's definitely room for accidents and mixup if you're not extremely careful. Just say no.
Most of the time, I use python. Python requires you to use self.foo in order to access the attribute foo of the instance of the current class. That way, the problem of confusing local variables, parameters and attributes of the instance you work on is solved.
Generally, I like this approach, even though I dislike being forced to do it. Thus, my ideal way to do thos is to not do it and use some form of attribute access on this or self in order to fetch the member variables. That way, I don't have to clutter the names with meta-data.
I'm weirdo and I prefix member variables with initials from the class name (which is camel-cased).
TGpHttpRequest = class(TOmniWorker)
strict private
hrHttpClient : THttpCli;
hrPageContents: string;
hrPassword : string;
hrPostData : string;
Most of the Delphi people just use F.
TGpHttpRequest = class(TOmniWorker)
strict private
FHttpClient : THttpCli;
FPageContents: string;
FPassword : string;
FPostData : string;
If the language supports the this or Me keyword, then use no prefix and instead use said keyword.
another trick is naming convention:
All member variables are named as usual, without any prefix (or 'this.' is it is usual to do so in the project)
But they will be easily differentiated from local variable because in my project, those local variables are always named:
aSomething: represents one object.
someManyThings: list of objects.
isAState or hasSomeThing: for boolean state.
Any variable which does not begin by 'a', 'some' or 'is/has' is a member variable.
Since VB.NET is not case-sensitive, I prefix my member variables with an underscore and camel case the rest of the name. I capitalize property names.
Dim _valueName As Integer
Public Property ValueName() As Integer
I'm with the people that don't use prefixes.
IDEs are so good nowadays, it's easy to find the information about a variable at a glance from syntax colouring, mouse-over tooltips and easy navigation to its definition.
This is on top of what you can get from the context of the variable and naming conventions (such as lowerCamelCase for local variables and private fields, UpperCamelCase for properties and methods etc) and things like "hasXXXX" and "isXX" for booleans.
I haven't used prefixes for years, but I did used to be a "this." prefix monster but I've gone off that unless absolutely necessary (thanks, Resharper).
A single _ used only as a visual indicator. (C#)
helps to group members with intellisense.
easier to spot the member variables when reading the code.
harder to hide a member variable with a local definition.
_ instead of this.
I use _ too instead of this. because is just shorter (4 characters less) and it's a good indicator of member variables. Besides, using this prefix you can avoid naming conflicts. Example:
public class Person {
private String _name;
public Person(String name) {
_name = name;
}
}
Compare it with this:
public class Person {
private String name;
public Person(String name) {
this.name = name;
}
}
I find the first example shorter and more clear.
It kinda depends what language you're working in.
In C# you can reference any member using the 'this' prefix, e.g. 'this.val', which means no prefixes are needed. VB has a similar capability with 'Me'.
In languages where there is a built-in notation for indicating member access I don't see the point in using a prefix. In other languages, I guess it makes sense to use whatever the commonly accepted convention is for that language.
Note that one of the benefits of using a built-in notation is that you can also use it when accessing properties and methods on the class without compromising your naming conventions for those (which is particularly important when accessing non-private members). The main reason for using any kind of indicator is as a flag that you are causing possible side effects in the class, so it's a good idea to have it when using other members, irrespective of whether they are a field/property/method/etc.
I use camel case and underscore like many here. I use the underscore because I work with C# and I've gotten used to avoiding the 'this' keyword in my constructors. I camel case method-scoped variants so the underscore reminds me what scope I'm working with at the time. Otherwise I don't think it matters as long as you're not trying to add unnecessary information that is already evident in code.
I've used to use m_ perfix in C++ but in C# I prefer just using camel case for the field and pascal case for its property.
private int fooBar;
public int FooBar
{
get { return fooBar; }
set { fooBar = value; }
}
I like m_ but as long as convention is used in the code base is used I'm cool with it.
Your mul_ example is heading towards Charles Simonyi's Apps Hungarian notation.
I prefer keeping things simple and that's why I like using m_ as the prefix.
Doing this makes it much easier to see where you have to go to see the original declaration.
I tend to use m_ in C++, but wouldn't mind to leave it away in Java or C#. And it depends on the coding standard. For legacy code that has a mixture of underscore and m_ I would refactor the code to one standard (given a reasonable code size)
I use #.
:D j/k -- but if does kind of depend on the language. If it has getters/setters, I'll usually put a _ in front of the private member variable and the getter/setter will have the same name without the _. Otherwise, I usually don't use any.
For my own projects I use _ as a postfix (as Martin York noted above, _ as a prefix is reserver by the C/C++ standard for compiler implementations) and i when working on Symbian projects.
In Java, one common convention is to preface member variables with "my" andUseCamelCaseForTheRestOfTheVariableName.
None if it's not necessary, single underscore otherwise. Applies for python.
If it is really necessary to prefix member variables, I would definitely prefer m_ to just an underscore. I find an underscore on its own reduces readability, and can be confused with C++ reserved words.
However, I do doubt that member variables need any special notation. Even ignoring IDE help, it isn't obvious why there would be confusion between what is a local and what is a member variable.
Closed. This question is opinion-based. It is not currently accepting answers.
Closed 5 years ago.
Locked. This question and its answers are locked because the question is off-topic but has historical significance. It is not currently accepting new answers or interactions.
Jeff finished his post talking about this, but I don't catch the idea.
So, why do you think this is a bad coding style?
EDIT:
I, as a lot of you, don't think that it is a bad coding style. But Jeff is far better programmer than me, and his point of view turned on lights on my head to get answering if I was wrong. I was a Delphi developer for some few years and am becoming a C# developer now, and in Delphi it was a common practice.
All caps is the traditional C designation of a preprocessor macro constant. It's very useful to have these in a different namespace from anything else, since the preprocessor will substitute wherever it finds the name, regardless of things like scope.
A constant in the sense that Jeff was using is, semantically, a variable that can't be changed. It obeys all scoping principles and everything, and is semantically identical to a non-const variable with the same value.
To put this another way,
#define max_length 5
is a problem because somebody might use max_length as a variable in a different context, where it would normally be safe, while
const int max_length = 5;
is simply a variable declaration. Therefore, there's an advantage in using
#define MAX_LENGTH 5
because the convention is that only preprocessor constants are all-caps, so it will not interfere with any other use.
You'll find that a lot of Jeff's statements are controversial first, with accuracy being a secondary concern. His blog wouldn't be that popular if he weren't occasionally inflammatory. (Consider the last line of Death to the Space Infidels, "That said, only a moron would use tabs to format their code.") It's honestly subjective. Don't take everything he says as True and Good -- it's not meant to be. If you disagree, go kick his ass in the comments, and see if he writes back. :)
I think ALL_CAPS_CONSTANTS are perfect: they're instantly recognizable and familiar. Part of my workplace's style guidelines (and we don't have that many) is to write all static constants in caps. Don't sweat it; just use whatever the rest of your team uses. Deciding on StudlyCaps vs. camelCase vs SCREAMING_CAPS is worth maybe 90 seconds discussion.
Screaming is fine. In the case of the constant it tells the reader
DONT THINK ABOUT CHANGING ME LATER IN
CODE
But I understand if soft programmers get offended.
Frankly, I don't think it is bad coding style. Indeed, even the official Java code style makes constants all capitals (http://java.sun.com/docs/codeconv/html/CodeConventions.doc8.html), as do other language conventions.
In theory, it's harder to read - we humans like to use the variable height of letters to increase reading speed (we can infer a lot of information from just rough word shape and the first/last letters). However, I don't have a problem with short, all capital phrases. It's hardly "shouting" (you compiler doesn't exactly care how rude you are), and clearly shows the names are potentially mutable, and those that are not.
I don't think it's bad coding style. Maybe old-fashioned, but not bad. It does make constants stand out from other variables.
The only compelling reason to me is consistency in style. For non-.NET languages like Java / C++, all-caps constants are certainly acceptable.
For C#, the standard is to use PascalCase, as noted here: C# naming convention for constants?
ALL CAPS IS LIKE SHOUTING AT SOMEONE.
IT ALSO MAKES THE CODE HARDER TO READ
Jeff has some additional things to say on this in the comments:
However on the other side and the reason I do still use the all caps and
underscore
Less code? That's a worthwhile cause
deserving of serious discussion.
But whether you call something "foo",
"Foo", "_foo", or "FOO"? Meh.
Naming conventions are highly
controversial and religious.
Developers should pick something they
like, something that's hopefully not
too much at odds with the "local
conventions", and just go with it. A
lot of discussion and hand-wringing
over naming isn't worthwhile.
That said, I think ALL CAPS IS REALLY
HARD TO READ!
I also use this for constants, but I also can understand why some people don't like it. It's a bit like writing everything in lowercase in german or other languages.
Well, there's the old readability issue. Normally-cased test is just easier to read.
There are exceptions, though. Languages like SQL are usually all upper-case (although case-insensitive).
Also, there are other uses, like to distinguish between "constants" and regular variables, which you'll see in a lot of languages like PHP, Python, etc., even though Jeff for some reason doesn't like that, and it is apparently against the C# code style guidelines.
So generally, I don't think it's wrong anywhere, but I do think that one should always try and follow the general best practises. When in Rome, do as the Romans – when coding Python, follow PEP 8 :)
FLIP THE QUESTION, WHY USE ALL CAPS?
I don't think that it is wrong. Mostly, it's a personal choice.
For your personal coding, do what you want.
For you professional coding, follow company policy.
Just like writing everything in bold is not a good idea
I remapped my capslock to a ctrl key (woo emacs!). So I think its bad style when I have to type 30-character names while holding down shift
Some people consider ALL CAPS to be "old school". Consider the difference between:
const string ErrorMessage = "Some error message.";
and
const string ERROR_MESSAGE = "Some error message.";
Both are completely usable, but the ALL CAPS version is less used by newer developers, such as the ones that started out with .NET.
I consider it a bad coding style if your team is using a different style. Other than that, I don't really care. At least when I see ALL CAPS in some shared code, I can guess that it's a constant.
#ck,
BECAUSE IT'S CONVENTION.
I use ALL_CAPS for macros and preprocessor symbols. So my pre-C99 C constants are ALL_CAPS, but not in any other language I know of.
Constants and CONSTANTS might differ. Use all-caps only when dealing with preprocessor, that being said for example in C++ it's recommended to avoid that and use const variable or constexpr which would be named just like any other variables (maybe with some prefix or something to make it clear that it's a constant but...).
What makes a language strongly typed? I'm looking for the most important aspects of a strongly typed language.
Yesterday I asked if PowerShell was strongly typed, but no one could agree on the definition of "strongly-typed", so I'm looking to clarify the definition.
Feel free to link to wikipedia or other sources, but don't just cut and paste for your answer.
The term "strongly typed" has no agreed-upon definition.
It makes a "great" argument in a flamewar, because whenever someone is proven wrong, they can just redefine it to mean whatever they want it to mean. Other than that, the term serves no real purpose.
It is best to just not use the term, or, if you use it, rigorously define it first. If you see someone else use it, ask him to define the term.
Everybody has their own definition. Some that I have seen are:
strongly typed = statically typed
strongly typed = explicitly typed
strongly typed = nominally typed
strongly typed = typed
strongly typed = has no implicit typecasts, only explicit
strongly typed = has no typecasts at all
strongly typed = what I understand / weakly typed = what I don't understand
strongly typed = C++ / weakly typed = everything else
strongly typed = Java / weakly typed = everything else
strongly typed = .NET / weakly typed = everything else
strongly typed = my programming language / weakly typed = your programming language
In Type Theory, there exists the notion of one type system being stronger than another. In particular, if there exists an expression e1 such that it is accepted by a type system T1, but rejected by a type system T2, then T2 is said to be stronger than T1. There are two important things to note here:
this a comparative, not an absolute: there is no strong or weak, only stronger and weaker
there is no value implied by the term; stronger does not mean better
According to B.C. Pierce, the guy who wrote "Types and Programming Languages and Advanced Types and Programming Languages" :
I spent a few weeks trying to sort out
the terminology of "strongly typed,"
"statically typed," "safe," etc., and
found it amazingly difficult... The
usage of these terms is so various as
to render them almost useless.
So no wonder why your collegues disagree.
I'd go with the simplest answer : if you can concatenate a string and an int without casting, then it's not strongly typed.
EDIT: as stated in comments, Java just does that :-(
The key is to remember that there is a distinction between statically typed and strongly typed. A strongly typed language simply means that once assigned, a given variable will always behave as a certain type until it is reassigned. By definition statically typed languages like Java and C# are strongly typed, but so are many popular dynamic languages like Ruby and Python.
So in a strongly typed language
x = "5"
x will always be a string and will never be an integer.
In certain weakly typed languages you could do something like
x = "5"
y = x + 3
// y is now 8
People are confusing statically typed with strongly typed. Statically typed means "A string is a string is a string". Strongly typed means "Once you make this a string it will be treated as a string until it is reassigned as something different."
edit: I see someone else did point this out after all :)
I heard someone say in an interview (I think it was Anders Hejlsberg of C# and turbo pascal fame) that strong typing is not something that's on or off, some languages have a stronger type system than others.
There's also a lot of confusion between strongly, weakly, static and dynamic typing where staticly typed languages assign types to variables and dynamic languages give types to the objects stored in variables.
Try wikipedia for more info but don't expect a conclusive answer:
http://en.wikipedia.org/wiki/Strongly_typed_language
Strongly typed means you declare your variables of a certain type, and your compiler will throw a hissy fit if you try to convert that variable to another type without casting it.
Example (in java mind you):
int i = 4;
char s = i; // Type mismatch: cannot convert from int to char
The term 'strongly typed' is completely and utterly nonsensical. It has no meaning, and never did. Even if some of the claimed definitions were accurate, I see no purpose as to the reason for distinction; Why is it important to know, discuss or debate whether a language is strongly typed (whatever that may mean) or not?
This is very similar to the terms 'Web 2.0' or 'OEM', which also have no real meaning.
What is interesting to consider, is how these phrases begin, and take root in everyday communication.
Statically typed language is one where the variables need to be declared before they can be used. While a Dynamically typed language is one where the variables can be used anytime, even if they are not declared. The only condition is that they must be initialized before they can be used.
Now, let us come to Strongly typed language. In such a language the variables have a type, and they will always be that type. They cannot be assigned to a value of another type. While a Weakly typed language is one where variables don't have a type. One can assign value of any type to them.
Example:
Java is a statically typed as well as strongly typed language. It is statically typed, because one has to declare the variables before they can be used. It is strongly typed, because a variable of particular type int will always hold integer values. You can't assign boolean to them.
Powershell is a dynamically typed as well as weakly typed language. It is dynamically typed as variables need not be declared before using them. it is weakly typed as variable may hold value of one type at certain point while a value of another type at different point of time.