45

It's not a problem to define a variable within a loop. In fact, it's good practice, since identifiers should be confined to the smallest possible scope. What's bad is to assign a variable within a loop if you could just as well assign it once before the loop runs. Depending on how complex the right-hand side of the assignment is, this could become rather ...


36

Yes, it's fine (actually, it's good) to make the default constructor unusable if there's no sensible way to initialize the object without any arguments. But don't "disable" it by throwing an exception. Make it private instead. Ideally your interface won't contain any methods or constructors people "aren't supposed to" call.


25

In the 2nd approach you will never have a half-initialised Foo. Putting all the construction in one place seems a more sensible, and obvious place. But... the 1st way isn't so bad, and is often used in many areas (there's even a discussion of the best way to dependency-inject, either property-injection like your 1st way, or constructor injection like the ...


24

Both approaches bundle the initialization code into a single function call. So far, so good. However, there are two issues with the second approach: The second one does not actually construct the resulting object, it initializes another object on the stack, which is then copied over to the final object. This is why I would see the second approach as ...


21

What allows the some languages to do this and others to not? Why not keep a uniform system of adding the semicolon to the end? Robert gave a good answer regarding Swift, I'll try to add bit more about parsing in general and why to use or not semicolons. When you compile the program, there are several steps before your source file is turned into executable ...


20

Complex types have non-trivial constructors and destructors. Those will get called at the start and end of the loop body (as it's initialized and goes out of scope). If the initialization is expensive like it needs to allocate some memory then that should be avoided. However for trivial types that is no problem. The allocation and deallocation itself is ...


14

Line breaks are used instead of semicolons to delimit the end of a statement. In Language guide: The Basics it says: Unlike many other languages, Swift does not require you to write a semicolon (;) after each statement in your code, although you can do so if you wish. Semicolons are required, however, if you want to write multiple separate statements on ...


11

There are two ways to deal with object state: Have extremely sophisticated debugging skills so that you can find obscure bugs, or Manage your state in a better way so that obscure bugs do not happen in the first place. Ways to better manage object state: Use constructors to build objects whose state is already valid. Make your state private. Write setter ...


9

Having static helper functions to create the constructor argument is a perfectly sane solution, but these functions are limited in what operations they can perform since they must produce exactly one argument each, and cannot communicate with each other. In the most general case where you want to adapt an interface Constructor(A, B, C) to a more usable ...


8

You pass them in via the constructor. If that means your constructor is too large, then maybe your giant class shouldn't be so giant. There are very few things in the world that have 5+ independent, but cohesive elements.


8

My thoughts are that if your object serves as a means to transfer data (and therefore purely output/input in a sense), the better thing is to not render objects mutable if they need not be and that this overrides readability when it is a toss up like this. The logic being that the absence of public setters says more about what purpose the class serves and ...


7

Initializing a variable as Telastyn pointed out can prevent bugs. If the variable is a reference type, initializing it can prevent null reference errors down the line. A variable of any type that has a non null default will take up some memory to store the default value.


7

Initializing as a parameter breaks encapsulation in that the caller can then do with the passed in list what it wants (clear at odd times). ArrayList<String> list = new ArrayList<String>(); Initializer init = new Initializer(list); //do various thing list.clear(); //now the list in init is also empty while init may still expect it to be filled ...


7

Uninitialized variables make a program non-deterministic. Each time the program runs, it may behave differently. Unrelated changes to operating environment, time of day, phase of the moon and permutations of such affect how and when these daemons manifest. The program may run a million times before the defect presents, them may do it every time, or run ...


7

C++ and Go are designed to compile to native machine code. Both have a phase during building where separate modules are linked together to produce a single combined module. Once this has been done, a complete list of all available objects is available. Therefore, the easiest way to initialise any object that requires initialisation is to scan that list, ...


7

The two are equivalent. The second would (officially) require an implicit copy if (and only if) the type of the initializer differed from the type of the object being initialized. In reality, even in that case most compilers can normally generate code that elides the copy.


7

This shows that the author is using modern C++ (e.g. >= C++11) and applies good practice: Braced initialization is the most widely usable initialization syntax, it prevents narrowing conversions and it's immune to C++'s most vexing parse. -- Scott Meyers, in Effective Modern C++, Item 7 You have to be aware that there might however be a subtlety ...


7

Either deploy the initial instance of your database with all the samples, so the data is already there before the application starts the first time, or test if any of the data is already there in the database, and populate if it is not. Depending on how the data is structured, a simple "SELECT COUNT(*)" may be enough for this. Furthermore, think about ...


6

Well, his advice is slightly too simple (that's an understatement). Following it ranges all the way from a good idea over who cares and bad idea to impossible. You should follow it whenever re-using is cheaper than destroying the old and creating a new one. #include <iostream> #include <string> int main() { std::string s; // Don't ...


6

You should choose between init in declaration or constructor, not both. In a language that has a default constructor where you don't have to explicitly provide a constructor if the default is all you need, a declaration init may be fine. As soon as you need an explicit constructor with parameter, I tend to move everything to constructor(s), to ensure that ...


6

Trying to use an uninitialized variable is always a bug, so it makes sense to minimize the probability of that bug occurring. Probably the most common approach programming languages take to mitigate the problem is to automatically initialize to a default value, so at least if you forget to initialize a variable, it will be something like 0 instead of ...


6

Since it is an internal class, there is no benefit to using read/write automatic properties; you are creating lots of get/set methods in your resultant IL. Assuming you are using C# 6, you have two options: 1 Make the class invariant: internal class MyClass { internal MyClass(int property1, int property2, int property3, int property4, int property5, ...


6

Yes, there is one. Those brackets disable implicit narrowing conversions, so if the type of the expression inside does not fit an int it's an error instead of a silent loss of data. Of course, 99 is plenty small and thus of type int. Try it with a sufficiently large literal like 99999999999: http://ideone.com/D89wVx


6

That is correct. Instead of making ExoPlayer implementation instantiate every single Renderer there is, you instantiate only those that you actually need for that particular implementation, and then inject them into the implementation, thus decoupling the ExoPlayer class from Renderer class. See Dependency Injection for more details.


5

You want a "mixin". In C++ they are usually implemented with templates and specifically using CRTP, the "curiously recurring template pattern". It might be an overkill if it's just a bit of common code, than Pierre's answer seems most appropriate. But as the amount of common code for the mock classes grows, so will value of template. Basic CRTP would go ...


5

In most plugin systems in C and C++, the loading of plugins works like this: The main application specifies a path where the plugins should be located (or allows such a path to be configured). On startup, the application looks for either dynamically loadable libraries (DLLs on Windows, .so on Linux, in case of compiled plugins) or scripts (in case of ...


5

Initializing, implies that the initial value matters. If the initial value matters, then yes, clearly you must make sure it is initialized. If it doesn't matter, that implies that it will get initialized later. Unnecessary initialization causes wasted CPU cycles. While these wasted cycles might not matter in certain programs, in other programs, every ...


5

I'm sure there are situations where this would make sense to do, particularly if you're writing a small application, but in general I think it would be a bad idea. You could apply any argument that you could make about global variables to static variables - they're still changeable anywhere in the application. If your application (and dev team) is ...


5

In languages like C, newly-declared variables essentially point to a (more or less) random memory location. If you declare the variable without also initializing it, it will contain whatever random value the memory happens to contain at the location in memory that the new variable points to.* Using the variable in this state will cause unpredictable ...


5

Injecting any value comes from the concept of dependency injection. At it's core, dependency injection defers to run time the actual implementation of an interface it is going to use for your application. Here are a few characteristics: You code to interfaces. This allows easy mocking or stubbing for unit tests and using the real code in production ...


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