11

I know in C#, by default, objects are passed by reference That's not correct. In C#, parameters are passed by value by default. But if that parameter is a reference type (like a class or interface), then it's the reference that's passed by value, not the object itself. If you actually want to pass by reference, you need to use ref, out or in. However I ...


7

imagine an implicit enumeration I think this is the key point. Implicit means not an actual enum type, but, say, numbers with special meaning. const int A = 1; const int B = 2; const int C = 3; And a method that is using the switch statement: public void DoSomething(int type) { switch (type) { case A: // Stuff ...


6

That is perfectly fine. This is often the compromise between the "passing everything in makes it too complex!" and the "using a static directly makes things inflexible and hard to test!" camps. Personally, I would only do this if the common (75%+) usage is to use the default instance. Otherwise, people will go with the easiest route (less arguments) which ...


5

No, you absolutely should not choose variable names to conform to your language's default values. The point of variable names is to make reading code easier for the maintainer. Default values are a detail of the language specification (or sometimes even of the implementation) and may or may not match with your intent in using a flag variable. Therefore it'...


5

You need to migrate some data. This logic belongs in that script. The script should change current entries to 15, but you absolutely shouldn't leave artifacts of that decision in your schema. After the migration, the number '15' isn't part of your domain, so shouldn't appear in a constraint or default. If you expect to be able to change this default value ...


4

Why allow the impossible? I believe that I should be setting the Method property to string.Empty by default, and if the user doesn't supply the Method then the service won't execute (I.E. I'll check for that, and throw an exception if they didn't supply it). Why? Why would you create a parameterless constructor if you know that it's going to blow up ...


4

Using try/catch for logical branching is not recommended in general, but there are legitimate uses. One example, when you have to query a third party API, and there is no other way to access it. To keep you code more readable, you could encapsulate the try/catch in single, isolated function like function GetSomethingFromThirdPartyApi(parameter, ...


4

In a word - no With a compiler the emitted code would probably be identically anyway, with an interpreter it will be more or less be the same, if anything slightly quicker.


3

You're overthinking it. A distributed cache's goal is to optimize performance, nothing more. If you expect data to always be cached, your design is flawed. You may not have the data for a bunch of reasons other (and much more current) than the unavailability of the cache service: The data was not cached yet, The data became obsolete and should be ...


3

If those parameters are not optional, then raise an exception. Is they shoudn't be optional, then Intelligent defaults are a good idea. Also if GameBaseClass is a top abstraction, you are adhering to the Dependency Inversion Principle. Your class depends on an abstraction not on a concretion.


2

An aside: You have parameters default value set to null and then the first thing you do is null check them. Have you tried method overloading. Ie public static function MakeFromName(String mystring) { MakeFromName(mystring, GameBaseClass.INSTANCE.currentAtlas, GameBaseClass.INSTANCE.currentData) }


2

Yes, it's very bad practice, for several reasons, including at least: Global state is bad in general. By having code that only uses the global state when the argument is null, you allow it to be used correctly and to be tested, but any other code that uses your code with a null argument then becomes problematic, as it inherits this global state. If you have ...


2

This is one of those questions where you might get two equally valid answers from different sides of the camp. You mentioned you don't want an explanation on pros and cons of different approaches, so let me just get straight to the core of your question. Is a magic number default value for a table column considered part of business logic? The answer is ...


2

I remember early in my career writing a series of if else if statements which I thought covered all cases. At the end I added: else { Throw new Exception("THE IMPOSSIBLE HAPPENED!!"); } Of course some months later my boss approached me with a worried look on his face, "Ewan, what does 'The impossible happened' mean?!". It means you have forgotten ...


1

You should either duplicate the defaults, or store them in variables that can be used in both places. Here's why: the compute function needs to know what the defaults are so that it can properly configure its behavior. The CLI wrapper needs to know what the defaults are so that it can properly configure its behavior. Since neither one has awareness of the ...


1

Ultimately I think this might be opinion based, but given that you are using a specific framework (Karma) and this framework has documentation, it is fine to omit default values. An exception would be if those default values get overridden in different build or deployment configurations. If the default is overridden by a different build config, I would ...


1

Alternative approach would be to have an enum (or based on your programming language a type with only two possible values, but with more descriptive names then true/false) public enum SoundState { On = 0, // 'On' by default Off = 1 } Then your code will looks more straightforward about it's intention. public class Setting { public SoundState ...


1

There should be no default configuration. Using the production configuration as default is problematic because this config is necessarily incomplete (e.g. credentials) this config might accidentally lead to devs accessing production resources production config changes would require changes to the default config Similarly, using a development configuration ...


1

I would approach this from a risk-based stance. Some development options can be detrimental or downright dangerous if set in a production environment. For those options, your default should be to set the production settings. These options are things like sidestepping caches, or enabling debug mode. Conversely, some production settings should be avoided or ...


1

/lib/doer.py shouldn't know about the default at all. Remove the default parameter and have /bin/runner pass in the correct config file to use. If opts is a dictionary, use code like this: backup_conf_file = opts.get("backup_conf_file", "/etc/thing.conf") That will give you either the value in the dictionary or /etc/thing.conf. If these are command line ...


Only top voted, non community-wiki answers of a minimum length are eligible