Tag Info

New answers tagged

1

Both of those code fragments are doing way too much work. You can replace them with int sum = 40; (in fact, if you gave those code fragments to a compiler, that's basically what the compiler would do). There's a famous trick for summing up the first n integers I used to do it in my head, but if you didn't know the trick and had no calculator handy, you ...


1

My suggestion would be to extract that logic out into a method so that if you add more conditions or even change your condition it is easier to maintain in one place + it is more testable. The reason I am suggesting that is because I am assuming this is not the actual problem but it is a more simplified version of your problem that you have narrowed it down ...


3

As it stands right now (a single condition) I don't see much reason to prefer one over the other, but I'd probably prefer the second as slightly simpler. When, however, your set of conditions are more complex, some variant of the first can be preferable, often by a wide margin. Consider something like: for (...) { if (i != 5 && (i%2!=0) ...


0

A for loops natural tendency is to "continue" and as others have pointed out, it's an extra line of code. In 15 years of writing code I have MAYBE used continue (in any language) 3 times; and none of that was recent. It's simply not a necessary construct as you quickly realize.


0

Any reason to prefer one over the other? At some places and in some languages, the use of continue and break are frowned upon as glorified gotos. They make it harder to read the code since you need to stop and then find the end of the loop you're in rather than noting the condition and reading along. The second version will work in pretty much any ...


5

I personally would go with the first example, given your task. The first example more closely matches your original problem statement. The 2nd requires a little bit more mental parsing to determine if it fulfills your problem statement. Look at how you worded what is going on: "Sum the numbers from 0 to 9 skipping 5". That is exactly what the first ...


0

Technically he will have one more line of execution for the continue statement. Otherwise, the code is identical. It is O(n) in both cases.


5

My problem is that the code that I have inherited is, in my opinion, absurdly over-engineered. I have enormous problems following the program flow and finding any concrete implementations of anything. The amount of abstractions are totally mind-boggling and there is no documentation whatsoever. Its not you, I find that a lot of C# and Java (and ...


4

The heart of creating abstractions is to give things a good name, which makes clear what a specific data type represents. And that's what you are doing here, no less, no more. Creating the right abstractions is what makes actually the difference between good code and bad code, so yes, assumed these abstractions serve you well, that is good practice.


1

In general, using a typedef is never really a bad thing, all it does is tell the compiler that when you use, say "Transform," you actually meant "Mat4." All typedef does is make it easier for the programmer to specify between separate types. There is usually no downside to using typedef. Overall, it is neither a good nor bad practice. Just make sure you can ...


3

In your second example, the Map should be a private static member to avoid redundant initialization overhead. For large amounts of values, the map will perform better. Using a hashtable, one can look up the answer in constant time. The multiple-if construct has to compare the input to each of the possibilities until it finds the right answer. In other ...


3

The point is to move the creation of the hashmap outside the function and do it once (or just less times than otherwise). private static final Map<String, Integer> map; static{ Map<String, Integer> temp = new HashMap<String, Integer>(); temp.put("A", 12); temp.put("B", 21); temp.put("C", 45); map = ...


1

what way is correct ... Being cynical just for a moment, none of them. Try as we might; we never get it completely right. But we can try. ... for performance ... Database. For raw data processing power, leverage your DBMS. You don't say which one you're using but all the Big Players have some sort of procedural language (PL/SQL, T-SQL, ...


5

Unless you have something which the application must supply all the time, I think it would be best to let the database related stuff be handled by the database itself. This will allow you to have the DB to do all the heavy lifting, while allowing the application to remain as lightweight as possible so that it can handle whatever it is that the user needs ...


1

There are many reasons to select by an id. I think the spirit of that message from lint is that you should primarily apply styling by classes. Selecting by id can be the exception where your styling is shared across similar elements, except this one, or only this one. You can use classes to act as an id, but I think thats probably evangelism. That'd be ...


2

ID's are needed to be unique while classes tend to group several elements' style together. I read somewhere it as this analogy : <student id="JonathanSampson" class="Biology Calculus" /> <student id="MarySmith" class="Biology Networking" /> Student ID cards are distinct. No two students on campus will have the same student ID card. ...


-2

If your tool says “Don't use IDs in selectors”, just throw it away and get a better tool. There is no reason to spend time and energy in “understanding” messages from a linter that does not understand the topic it is purported to cover.


0

Using ids is like using singletons, and singletons are not very good style. For prototype, yes, but in you're trying to make things right, do not presume that "this kind thing will always be here once and only once" unless you know for sure. It's more flexible to be prepare for 0 and many, not just for 1. And of course, the CSS precedence is valid concern ...


2

I think the gist of the argument, for those that agree with it, is to use class for css selectors instead of id. This avoids unintended css precedence rules from kicking in. If you know what you're doing (re class vs id selectors), and it works for you, I wouldn't change just for the sake of changing, though. From http://csslint.net/about.html: IDs ...



Top 50 recent answers are included