New answers tagged coding-style
0
I’d find that rule very unhelpful, and it leads to worse code and more bugs. In newer languages it is very bad. In Swift for example, and probably in other languages, it is a very good idea to have variables that only are assigned a value once - and that means they must be declared in a nested scope in practice.
0
Your naming convention looks like a variant of Hungarian notation where the acronyms correspond to semantic categories and replace the type.
As with all naming conventions: there is no good nor bad practice. The most important point is to use the convention consistently.
To answer this question objectively, one could only look at pros and cons:
The pros in ...
-1
Possible reason: Documentation
Using a named variable shows clear intent and explicitly states that this is indeed what was meant by the one implementing it. E.g.
bool IsFalling => Speed.y < 0f;
// vs
bool IsFalling => Speed.y < Zero;
The latter should prevent anyone reading the code (possibly even the one who wrote it) from even having to start ...
0
A series of guard clauses forms a list. A single nested if structure forms a tree.
The former is a one-dimensional data structure; the latter is two-dimensional.
The mental effort to understand a one-dimensional structure is comparable to that required to understand a two-dimensional structure only for trivial n (as in your example, where n is 2). If you ...
1
That it's a void method is irrelevant. We still have to return or throw on each branch; we still want to make early exit conditions orthogonal (apart from other concerns, the alternative could lead to more cases, more lines of code & deeper nesting); we still don't want to execute any code unnecessarily. If anything, void methods make this pattern even ...
1
Good answer here already. I would like to suggest going a step further and refactor this to something along the lines of:
private static void ValidateInput(string[] files, char[] password)
{
string message = GetValidationMessage(files,password);
if(message.Length>0)
{
Console.WriteLine("Error: " + message);
}
}
...
1
Advantages of #1:
less indentation required (which affects readability specificially when more than one using variable is required)
less "noise" in code, since less brackets are required
Disadvantages:
only available in C# 8.0 (which works for .Net Core / .Net Standard, but is only experimentally supported for the classic .Net Framework)
the ...
1
The C# 8 using statement translates to try-finally blocks (1).
Your example
int bytesRead;
byte[] fileBytes = new byte[4096];
using FileStream fileStream = new FileStream(...);
while ((bytesRead = fileStream.Read(fileBytes, 0, fileBytes.Length)) > 0)
{
... // Do something
}
Will be translated to something like:
int bytesRead;
byte[] fileBytes = new ...
9
There's no great consensus on this, and it can vary from language to language.
That said, I'd encourage you to prefer the quick return pattern (#2 in the OP). Separating the condition from the error message make them hard to keep together in your head, which causes bugs and makes the code harder to read.
The nested conditional version also isn't great when ...
3
It seems like using the same variable 'i' to iterate through the two for-loops would overlap and cause errors.
Indeed, it would. Well, not "errors", so much as unexpected behavior. The code you have is syntactically fine; no C or C++ compiler that I know of would raise any warnings, much less errors. However, if you run it, you'll see that it ...
9
If you write down one call to getXY() in your code, and I read your code, then I know what happens: There is one call to getXY(), and if the result is either x or y then DoSomething() gets called.
If you write down two calls to getXY() in your code, and I read your code, then things are more complicated: There is one call to getXY() first. If the result is x,...
0
When wondering about coding style, it sometimes help to think in terms of real-world algorithmic operations.
A thirsty person walks by a convenience store, with only one coin in their pocket. Water bottles cost 50-cents (for all intents and purposes of this answer). Which one of the following would be the most typical reaction?
Option 1: Take the coin out of ...
2
IMHO the focus should not be on "style" here, but on not violating the DRY ("Don't Repeat Yourself") principle.
This code
if (getXY() == x || getXY() == y) {
DoSomething();
}
is not as DRY as it could be. For new equirements where getXY() needs to be replaced by something different, there will be two places to change instead of one (...
4
I think it comes down to this: do you know (does it seem) like this specific action should be extremely costly?
If so, then maybe it is a good idea to move it out of your condition, maybe even wrap it into something asynchronous or exception-catching (depending on specific language and libraries used).
I think your problem actually implies a better question: ...
Top 50 recent answers are included
