Tag Info

New answers tagged

8

Decompiling (as per Robert Harvey's suggestion) yielded the following, for anyone interested. This method: static T GenericMake<T>() where T : new() { return new T(); } Apparently, when compiled, becomes this: private static T GenericMake<T>() where T : new() { T t; T t1 = ...


2

For an authoritative answer, I would refer you to Eric Lippert's answer to that question on StackOverflow a few years ago, a snippet of which is briefly quoted below. However, in this specific case I can certainly give you some reasons why I would push back on the feature if it came up in a design meeting as a possible feature for a future version of ...


2

I going to go further than "Yes, they should be in" and say they're a basic requirement for any modern language and something I would just expect to work, at least 2 levels, preferably // and /* */ since that's what most developers are used to. While I agree with @Telastyn that: Leaving commented code in your code base is an anti-best practice with ...


8

I don't see a compelling argument here for non-line comments, and personally I cannot remember the last time I've used one. Comments in and of themselves are decreasing in frequency, and should be focused on explaining why code is doing stuff. That is done using line comments. Leaving commented code in your codebase is an anti-best practice with the ...


0

If you can access tokens with an index, there's the temptation to jump ahead or behind, and you can do so, however you generally wind up with very hard code to understand. Good parsers have a grammar which determines what they should look for next based on where they are in the grammar, and if the grammar is done right, you should never be faced with ...


2

Common parsing techniques rely on inspecting a single 'current' token from a stream of such tokens. In some variations a certain amount of lookahead is required, but is usually provided from within the parser and not by indexing forwards and backwards across the lexer stream. In other words the data structure you will most likely need is some kind of ...


0

Given that languages already exist that bracket the possible behaviours you are considering, the question is: which would suit your users better? To create a programming language you need an intended audience of developers who will use it. When you ask a question of this type you then ask which choices will suit your intended users better. If your users ...


4

You should consider that alternative systems can also be acceptable design decisions. Shells: 0 exit status is true, non-zero is false The example of shells treating a 0 exit status as true has already been mentioned. $ ( exit 0 ) && echo "0 is true" || echo "0 is false" 0 is true $ ( exit 1 ) && echo "1 is true" || echo "1 is false" 1 is ...


2

In many languages the convention is to use PascalCasing for types(the only exceptions I can think of are lisps and STL). Using camelCasing or snake_casing allows you to easily name a variable after it's type(like void foo(Bar bar)). snake_casing also allows that. You'll have to change more letters(remove underscores and decapitalize letters), but you get ...


5

There really isn't hard evidence for preferring camel-casing over pascal-casing. Though that doesn't stop people from arguing over it a lot. If you're consistent, then there's not a huge difference either way. No casing comes with disadvantage of providing no hints for what words start where, which makes it more difficult to mentally parse and can lead to ...


2

Even in languages that allow dynamic modification of a single instance, like Python or Ruby, the code of methods still only exists in memory once. The main difference between those languages and those where a single instance cannot be changed (like Java or C++) is that in the static languages, each instance conceptually holds a single reference to a list of ...


0

OOP concepts do not change if you compare them in different programming languages though the way it gets implemented might vary. I have been working on C++ for 2 years and before that I learnt and worked in Java as well. Here is how you can look at it. Classes are the blueprints based on which objects are generated. In other words class can be seen as ...


5

The relevant terms here are dynamic and static typing. With static typing, all the types are fixed and do not change during the execution time of your program. This is what traditional languages like C/Java/etc are doing. The advantage for compiled languages with static typing is that they know, that each object of your class will have the same methods, ...


2

I can think of a few useful scenarios where partials make sense, most of them I am using myself in my projects: To separate Tool/IDE/Designer generated code from the code you are maintaining. A good example is the Form.Designer.cs file that contains the designer generated code for windows forms applications. Many other .NET formats also have some tool ...



Top 50 recent answers are included