Background
I'm wanting to follow the most commonly-practised naming conventions for TypeScript. I've noticed that the official website shows code examples featuring Pascal-case for types and modules and camel-case for just about everything else.
Example
I'm currently implementing a property that encapsulates a backing value:
class SomeClass {
get status() {
return statusBackingField;
}
set status(newValue: Status) {
statusBackingField = newValue;
//Do other work here
}
statusBackingField: Status;
}
Problem
The name of the property is status. In C#, I would normally name the property Status and the backing value status. Since the convention is to use camel-case for properties, this doesn't work. I'm not sure which convention I should use for consistency with other TypeScript code in general.
Question
Other languages, such as C# and Java, seem to have official or de facto standard conventions. Is there any such authoritative or de facto standard convention for naming backing fields in TypeScript?
Notes
For the close-voters: please note that I'm not looking for opinions. I'm looking for objective information as requested in the summarised question above.
There is no code convention standard for TypeScript. Since it is a superset of JavaScript, following JavaScript code conventions would probably be the correct approach. In such a case you would use an underscore-prefixed property _status. Idiomatically, this also matches the compiler’s use of an underscore-prefixed _this for compiled arrow functions and underscored-prefixed _super for superclasses.
In C# as well as TypeScript we use private _status. In C# the property will be Status. In TypeScript as you mentioned it is status
I think it's safe to say at this stage that there is no standard.
If someone can point me to an authoritative standard or evidence of a de-facto standard, then I may consider accepting their answer instead.
Related
I realize that there is some subjectivity in the question, but considering that Apple development is pretty opinionated about naming conventions I want to do this in the way that others will understand what my coding is doing. I am trying to ask the question in the most generic way, But I'll add some of my specific details in the comments in case it affects your answer.
Let's say that I am supporting both iOS 6 and iOS 7. There is a new method on an existing class that only exists in the iOS 7 SDK. Assume that implementing the functionality in a way that is "good enough" for my app is fairly straightforward. But, of course, I'd rather use the SDK version as it is likely to be better supported, more efficient, and better handle edge cases.
As documented in this Q&A it is straightforward to handle this situation.
if ([myInstance respondsToSelector:#selector(newSelector)]) {
//Use the SDK method
} else {
//Use my "good enough" implementation.
}
But I don't want to litter my code with a whole bunch of conditional invocations. It seems that it would be better to encapsulate this dynamic method selection. (Especially in my case, where the method hasn't actually shipped yet and the name/signature might change.)
My instinct is to add a class category that implements both my functionality as well as a wrapper method that implements this dynamic selection of method.
Is this the right approach? If so, what naming conventions should I use? (I obviously can't name my method the same as the iOS7 method or there would be naming collisions.)
My gut reaction is to call my wrapper method safeNewSelector and my implementation a private method called lwNewSelector (where lw is my standard class prefix). But I'd much rather use something that would be considered a standard naming convention.
My instinct is to add a class category that implements both my functionality as well as a wrapper method that implements this dynamic selection of method.
That sounds right. The naming convention for category methods is a lowercase prefix, plus underscore. So, if you are shadowing a method called doSomething:withAwesome:, you would name your category method ogr_doSomething:withAwesome: (assuming you use OGR as your common prefix).
You really must prefix category methods. If two categories implement the same method, it is undefined behavior which will be run. You will not get a compile-time or runtime error. You'll just get undefined behavior. (And Apple can, and does, implement "core" functionality in categories, and you cannot easily detect that they've done so.)
Go for a category and chose a name that is pretty unique, for example prefixed by some company/project specific prefix. Let's say the method in iOS 7 is going to be called funky and you chose the prefix foo. Then you'd do:
#implementation SomeClass(FooCategory)
- (void)foo_funky
{
if ([self respondsToSelector:#selector(funky)]) {
[self funky];
} else {
// Implementation of workaround.
}
}
#end
Now, every time you'd call foo_funky that decision needs to be made. Pretty inefficient. It just occurred to me that Objective-C can make that more efficient by messing with the runtime, kind of like method-swizzling (following code is untested):
#implementation SomeClass(FooCategory)
- (void)foo_funky
{
// Empty implementation, it will be replaced.
}
- (void)foo_myFunkyImplementation
{
// Workaround implementation in case the iOS 7 version is missing.
}
+ (void)load
{
Method realMethod, dummyMethod;
realMethod = class_getInstanceMethod(self, #selector(funky));
if (!realMethod) {
// iOS7 method not available, use my version.
realMethod = class_getInstanceMethod(self, #selector(foo_myFunkyImplementation));
}
// Get the method that should be replaced.
dummyMethod = class_getInstanceMethod(self, #selector(foo_funky));
// Overwrite the dummy implementation with the real implementation.
method_setImplementation(dummyMethod, method_getImplementation(realMethod));
}
#end
This way every time you call foo_funky the correct method is called without the overhead of responds-to-selector-and-then-call-other-method.
You could also use the runtime class modifications to add your implementation using the official name when it's not available, but I don't recommend that. It's better when you can tell by the method name that it might not be the version you're expecting.
It is a fair question indeed and I think many Objective-C debs have run into this situation.
I have used the approach that you suggest, using a class category, in several places myself. As for the naming, in most cases I put a little extra functionality into my category method, so my method names most of the time take another argument – in most cases a simple animated:(BOOL)animated added to the end of the "official" method name.
Yes, there's a risk of clashing with future SDK releases, but I wouldn't worry too much about it, Xcode's refactoring works reasonably well and you'll get a linker warning when category methods conflict.
Edit:
As Rob points out, using that naming convention is probably a good idea.
It's common in a lot of classes in JDK, just a few examples:
java.util.Properties
load0
store0
java.lang.Thread
start0
stop0
setPriority0
Usually they are private native methods (like in Thread class), but sometimes they are just private (Properties class)
I'm just curious if anybody know if there is any history behind that.
I believe they are named like that because equivalent functions with same names exist in the code and just to distinguish between native helper functions and public functions they decided to suffix them with 0.
in java.util.Properties both load, store and load0, store0 exist.
The 0 after the method name is done so to distinguish between public and private methods having same name .
Start function will call the start0 function.
Those functions which ends with 0 is private method.
And those which are not ending with number is public.
You can check in any of the library.
The use of zero suffixes on method names is just a convention to deal with cases where you have a public API method and a corresponding private method. In the Java SE libraries, this is commonly used for the native methods that provide the underlying functionality implemented by the classes. (You can see what is going on by looking at the OpenJDK source code.)
But your questions are:
Why some java methods in core libraries end with numbers?
Because someone thought it would be a good idea. It is not strictly necessary since they typically could have overloaded the public methods instead. And since the zero suffix matters are private, the naming of methods should not be relevant beyond the class and its native implementation.
I'm just curious if anybody know if there is any history behind that.
There is no mention of this convention in the original Java Style Guide. In fact, I think it predates Java. I vaguely recall seeing it in C libraries in 4.x BSD Unix. That was the mid 1980's. And I wouldn't be surprised if they adopted it from somewhere else.
Every time I write trivial getters (get functions that just return the value of the member) I wonder why don't oop languages simply have a 'read only' access modifier that would allow reading the value of the members of the object but does not allow you to set them just like const things in c++.
The private,protected,public access modifiers gives you either full (read/write) access or no access.
Writing a getter and calling it every time is slow, because function calling is slower than just accessing a member. A good optimizer can optimize these getter calls out but this is 'magic'. And I don't think it is good idea learning how an optimizer of a certain compiler works and write code to exploit it.
So why do we need to write accessors, read only interfaces everywhere in practice when just a new access modifier would do the trick?
ps1: please don't tell things like 'It would break the encapsulation'. A public foo.getX() and a public but read only foo.x would do the same thing.
EDIT: I didn't composed my post clear. Sorry. I mean you can read the member's value outside but you can't set it. You can only set its value inside the class scope.
You're incorrectly generalizing from one or some OOP language(s) you know to OOP languages in general. Some examples of languages that implement read-only attributes:
C# (thanks, Darin and tonio)
Delphi (= Object Pascal)
Ruby
Scala
Objective-C (thanks, Rano)
... more?
Personally, I'm annoyed that Java doesn't have this (yet?). Having seen the feature in other languages makes boilerplate writing in Java seem tiresome.
Well some OOP languages do have such modifier.
In C#, you can define an automatic property with different access qualifiers on the set and get:
public int Foo { get; private set; }
This way, the class implementation can tinker with the property to its heart's content, while client code can only read it.
C# has readonly, Java and some others have final. You can use these to make your member variables read-only.
In C#, you can just specify a getter for your property so it can only be read, not changed.
private int _foo;
public int Foo
{
get { return _foo; }
}
Actually, no they aren't the same. Public foo.getX() would still allow the internal class code to write to the variable. A read-only foo.x would be read-only for the internal class code as well.
And there are some languages that do have such modifier.
C# properties allow to define read only properties easily. See this article.
Not to mention Objective-C 2.0 property read-only accessors
http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/ObjectiveC/Articles/ocProperties.html
In Delphi:
strict private
FAnswer: integer;
public
property Answer: integer read FAnswer;
Declares a read-only property Answer that accesses private field FAnswer.
The question largely boils down to: why does not every language have a const property like C++?
This is why it's not in C#:
Anders Hejlsberg: Yes. With respect to
const, it's interesting, because we
hear that complaint all the time too:
"Why don't you have const?" Implicit
in the question is, "Why don't you
have const that is enforced by the
runtime?" That's really what people
are asking, although they don't come
out and say it that way.
The reason that const works in C++ is
because you can cast it away. If you
couldn't cast it away, then your world
would suck. If you declare a method
that takes a const Bla, you could pass
it a non-const Bla. But if it's the
other way around you can't. If you
declare a method that takes a
non-const Bla, you can't pass it a
const Bla. So now you're stuck. So you
gradually need a const version of
everything that isn't const, and you
end up with a shadow world. In C++ you
get away with it, because as with
anything in C++ it is purely optional
whether you want this check or not.
You can just whack the constness away
if you don't like it.
See: http://www.artima.com/intv/choicesP.html
So, the reason wy const works in C++ is because you can work around it. Which is sensible for C++, which has its roots in C.
For managed languages like Java and C#, users would expect that const would be just as secure as, say, the garbage collector. That also implies you can't work around it, and it won't be useful if you can't work around it.
I am wondering why Qt uses Q before every class name rather than putting everything in a namespace. Is there any particular reason, such as making the names easy to search for, or is it just about brand names?
I believe it is historical. Namespaces were introduced into C++ around 1995. Qt development started in 1991 so namespaces could not be used, obviously.
It may be a portability issue. Namespaces weren't / aren't supported by every compiler, so the naming convention helps to cut down on naming clashes.
The documentation for Qt refers to namespaces, although I didn't check the code to see if they are truly c++ namespaces or a hack with public declarations inside a class. I would guess that the rest is trying to avoid causing everybody to need to rename everything, although they could provide a migration path if they wanted to, like so:
namespace Qt
{
class Object { ... };
}
#ifndef NO_OLD_DECLS
typedef Qt::Object QObject;
#endif
Qt is very conservative on the C++ language features it uses. No namespaces, exceptions or RTTI. See also this article detailing why templates are not used in signal/slot handling.
Seeing as there's not a single C++ compiler left that doesn't implement namespaces, nowadays there's only one reason: Branding :)
Qt uses a Q prefix as part of their coding style. It usually serves the purpose of making it easier to read the code and spot what is what.
An identifier that:
is prefixed with "Q" and suffixed with "Private" is a private class used for implementation details and is not part of the API (e.g. QPainterPrivate)
is prefixed with "Q" and not suffixed with "Private" is a public class (e.g. QWidget)
is prefixed with "q" (lowercase) is a public global function (e.g. qRgb)
Adopting a coding style and using it uniformly makes it much easier for other people to understand code they didn't write.
Ref.: Qt Coding Style
My question is rather simple and the title states it perfectly: How do you name your "reference" or "basic" implementations of an interface? I saw some naming conventions:
FooBarImpl
DefaultFooBar
BasicFooBar
What do you use? What are the pros and cons? And where do you put those "reference" implementations? Currently i create an .impl package where the implementations go. More complex implementations which may contain multiple classes go into a .impl.complex package, where "complex" is a short name describing the implementation.
Thank you,
Malax
I wonder if your question reflects the customs of a particular language. I write in C#, and I typically don't have "default" implementation. I have an interface, say IDistance, and each implementation has a name that describes its actual purpose / how it is specific, say, EuclidianDistance, ManhattanDistance... In my opinion, "default" is not a property of the implementation itself, but of its context: the application could have a service/method called "GetDefaultDistance", which would be configured to return one of the distance implementations.
In Java, (whenever suitable) I typically use a nested class called RefImpl. This way for a given interface InterfaceXYZ, the reference implementation is always InterfaceXYZ.RefImpl and there is no need to fumble around making up effectively redundant names.
public interface InterfaceXYZ {
// interface methods ...
public static class RefImpl implements InterfaceXYZ {
// interface method impls.
}
}
And then have a uniform usage pattern:
// some where else
public void foo () {
InterfaceXYZ anXYZ = new InterfaceXYZ.RefImpl();
...
}
I asked a previous question about a "null" implementation and it was identified as the null object pattern - an implementation of an interface that does nothing meaningful. Like Mathias, I'm not too sure what would be considered a "default" implementation that didn't have some kind of name specific to its implementation.
If the interface is a RazmaFrazzer, I'd call the implementation a DefaultRazmaFrazzer.
If you've already got several implementations and you've marked one of them out as a "default" look at all the implementations and look at the differences between them and come up with an adjective that describes the distinguishing feature of the default implementation e.g. SimpleRazmaFrazzer, or if it's a converter, you might have PassThroughDefaultRazmaFrazzer - so you're looking for whatever makes the implementation distinctive.
The exact convention doesn't metter - be it IService + Service or Service + ServiceImpl. The point is to be consistent throughout the whole project.