|
Instead of
this._x1 I would say use either
this.x1 or
_x1 Not both.
Kevin
|
|
|
|
|
Maybe.
On my first example i separated the X1 property from it's variable, so one is called "X1" (the property) and the other "_x1" (for the variable).
Next a other suggestion to make it an auto assign property (as in "int X1 { get; set; }"). To call the variable "x1" (lowercase) and the property not, i'd advise against it.
Althought C# has the resource to call the same name in 2 diferent elements as long as they don't share the same case configuration, it's not CLS complient, and i find it very confusing. So variables i name using the underscore, or some other element (like "m_x1" or "mX1").
So it could be:
public class What
{
protected int mX1;
public int X1 { get { return this.mX1; } set { this.mX1 = value; } }
}
Or even:
public class WhatElse { public int X1 { get; set; } }
Better yet, since it's now 1 line class! 
|
|
|
|
|
Spend 1/2 a day debugging this in C once. Granted, I was a n00b, but still.
for (int i=0; i<10; i++);
{
}
Took forever to discover why the "loop" executed only once! 
Latest Article - A Concise Overview of Threads
Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
Artificial intelligence is the only remedy for natural stupidity. - CDP1802
|
|
|
|
|
That's why sane people open the brace on the same line as the condition statement.
GCS d-- s-/++ a- C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
Like this?
for (int i=0; i<10; i++); {
}
|
|
|
|
|
/ravi
|
|
|
|
|
That's dreamweaver and android studio's default styling. Unfortunately, VS' default is to put opening brace on the next line.
|
|
|
|
|
Yeah, but that's a rare mistake that doesn't argue either way for the uses of braces for reading clarity. Braces around a single line makes it easier to see that it is (or should be) part of the conditional or loop it follows, rather than just the next line in your code. And after 8 hours of staring at code, the indentations may not be enough without those braces.
If you think 'goto' is evil, try writing an Assembly program without JMP.
|
|
|
|
|
I am pretty sure that if you used Resharper, it will point out the mistake right away.
|
|
|
|
|
I never make an indent of the following line(s) unless the line (i.e. last non-indented) ends in an opening brace.
If the single statement is short enough to fit on the same line as the enclosing statement, then there is no need for a brace.
for (int i = 0; i < 10; i++) SoundBeeper(); If it is too long (which is often the case, in particular if it is a function call with several parameters), I move it down to the next line, indent it, and end the first line with an opening brace,
for (int i = 0; i < maximumEntryCountInSet; i++) {
AddAnotherEntryToTheSet(rawData[i], parent, formatstring: standadformat);
}In the old days, the hardcopy code printout days, the braced form was more common: The maximum line length was often set at 80. Nowadays, with 99.5% of all code reading done on a large, high resolution screen, code lines often extend to 100 columns, with room for the first form in more cases.
You must use common sense, though! If a statement really represents a large, complex operation (of the kind 'AddAnotherEnytryToTheSet'), it certainly deserves a line by itself, with the accompanying indent and braces. You omit the braces and newlines and indent only for obvious, simple, trivial statements like SoundBeeper(), break / return, simple assignments etc. In 90% of cases, such trivial statements fit well within 100 (or even 80) cols, while calls to complex functions with several parameters easily break that limit. So usually the formatting goes by itself.
What I never do is identing without braces, and an opening brace always either ends the line, or is matched by a closing brace that ends the same line.
|
|
|
|
|
Urgh my eyes are burning!
Just imagine lot of people working on that code, maybe in 5 years, and not with your experience or focus. This is the perfect recipe for disaster.
Always... use... bracets..
|
|
|
|
|
Young programmers today refuse to believe that some explicit delimiters are k&r artifacts. Before k&r C, you could write e.g. "if X = 5 then y := 3;". After all, in plain text, you never write things such as "if (it is cold outside) {wear a jacket}". But in the Pascal example, the young programmers gasp: But... how can you know where the condition ends, if it is not enclosed in parentheses?
Noone has ever claimed that K & R were language design gurus. C was never "designed" at all, it just grew out of now forgotten B and BCPL, features added as they were needed, not as a result of any "lets sit down and plan what we might need, and then design a mechanism for it". So here and there they experienced "ooops! unless we add delimiters, there will be an ambiguity!"
Ending up with an excessive number of delimiter which are required only because the compiler needs it, due to poor language design, is somewhat ironic considering that a lot of programmers praised c as so much nicer that Pascal, becase you could write "{ }" rather than "begin end", saving several keystrokes (and you didn't consume as much punched paper tape ).
|
|
|
|
|
Explicit delimiters are present also in math, and are a necessary element of it. Want to say that is useless to use them since you can get how the equation goes out of the context? I think not.
From time to time, I see this idea of programming using natural language coming out. Something like: "hey, how good will be if we can program as we speak?". Useless to say I consider this a constrain to programming, which I see as a way more wide world.
Not to mention that people can associate different meanings to the same sentence, and this usually leads to (sometimes fatal) accidents. I don't wish to see this happening in programming. It shall be, in my opinion, something that should not be possible to read in another distorted way (depending on the mood or the context).
Just like math, parenthesis et all are there for a reason; skip them, and you wont pass the exam.
|
|
|
|
|
Sure, and in programming, they may be manadatory e.g. for delimiting a group of statements to be repeated.
But although it is permitted, in math, to write (3 + 5) = 8, but people would ask why you use them. You don't use them unless you want to override a general rule, such as multiplication / division before addition / subtraction. Or in expressions so complex that humans find it difficult to interpret them even if general rules are followed, so you add parentheses for clarification. But those are very rare cases; 99.99% of all real-life math expressions are so simple that the general rules for asocciation is sufficient, and no conceptually superfluous delimiters are used. You won't fail an exam in any school anywhere in the world because you write '3 + 5 = 8' rather than '(3 + 5) = 8'!
Programming in Pascal (and most other pre-C languages) you may of course use paretheses to override general rules such as operator precedence, but for a simple expression such as "if a + b = 8 ..." you don't need it. And the compiler won't barf if you omit parentheses.
The thing with C is that you must write "if (a + b == 8) ...", not to override precedence, not to improve readability by grouping terms, but because the parser is incapable of understanding it unless you give it a helping hand. The computer will barf if you omit them. That is a completely different reason, having nothing to do with the math side of it, nor with human comprehension. It is purely there for the compiler.
Statements in a programming language must be unambiguous; natural language is not. But programming languages other than C have certainly proven that a conditional statement can be unambiguous without enclosing the condition in parentheses.
I read one study, I believe it was done by a British university, where a number of test persons (all programmers) where given a program source code printout, and given a fixed time to study it, before answering a number of questions about the program. The program was the same for all test persons, but one group got it formatted in the spacious programming style, with e.g. 'if', if-clause, 'else', else-clause and maybe (I don't remember) braces each occupying a line. Other groups got the exact same code laid out to resemble "natural text", like 'if (itsRaining) UseUmbrella();' in one line. The study went though a number of programs and layout options.
The conclusion for this study was that the more the program layout resembled "natural text", the better was the comprehension of the program after a fairly short study. Those who read the natural text layout could answer more questions about the program functions, its structure etc. than those reading the loose programming style layout (which probably made the printout three times as many lines/pages). So some aspects of natural text were proven to be valuable, even without making a single change to the source code, only in its whitespace.
|
|
|
|
|
The problem never arise for the language itself; at the end compilers do their job in a quite good way. The problem comes when programmers (and not the original author) join this equation, so that they have to edit whatever is already there. This comes from experience in projects which lasts long and have multiple peoples joining efforts.
Too many time you see something like 'if(itsRaining) UseOmbrella();' becoming like 'if(itsRaining) UseOmbrella(); putOnBoots();' on the same line. The compiler will do it's job, and it will be correct by following the parsing rules, but the final outcome is wrong.
And again, not because the language is bugged, but becouse the human factor in programming has a really high impact factor (and must taken into account). There is a reason why software houses impose code-style and guidelines to programmer, and this is because everyone has it's own style, and this can impact future work done by some other programmers.
Between C peons like me there is the mantra of "always use parenthesis when writing pre-processore definitions".... and there is a reason for that! The if '(a + b == 8)' can assume a different meaning of what you do intend, and this happened to me!
That's why I'm defending my the portability, readability, extensibility of my code by using all the possible parenthesis and imposing an order which is "assumpted" to be correct (even when it's seems obvious), and this approach is giving fruits.
PS: Can you please provide a link to that study please, if you can? I'm interested now! Otherwise citing it does not make much sense, since it seems to be your opinion only, even if you say it's a paper/journal or whatsoever. In this era of fake new is dangerous to do claims such as "there is a study supporting my speech" without providing the source. Especially if your user name is "Member xxxxxxx".
|
|
|
|
|
If I have an if...else situation where both are single line statements I won't bother with braces, but if one is multi line I'll use braces for both to make it obvious they're related.
|
|
|
|
|
Similar here, and it looks neater in that situation. But if using VS I almost always use the "if" and "else" snippets, which auto-add the braces anyway.
Kevin
|
|
|
|
|
In my case, when the if has braces, the else will always have braces, but the if can be single-line, no braces, while the else has braces:
if (someCondition)
DoSomething();
else
{
DoSomethingElse1();
DoSomethingElse2();
}
I also never put the if and the single statement in the same line. When setting-up break-points or when debugging line by line, I don't want the if evaluation and the execution to happen together.
|
|
|
|
|
Star Trek Captains James T. Kirk, Jean Luc Picard, Kathryn Janeway, and MOST IMPORTANT, real-life Captain Chesley Burnett "Sully" Sullenberger III did!
Brace for Impact![^]
The best way to improve Windows is run it on a Mac.
The best way to bring a Mac to its knees is to run Windows on it.
~ my brother Jeff
|
|
|
|
|
I try not to, especially if it's just a return statement. But then, when that's the case, as long as the condition isn't already too long, I'll try to put it on the same line.
But then some editors will try to force it on the next line anyway.
|
|
|
|
|
what about conditional operators?
userCanVote = (userAge == 18) ? true : false;
I think this is the example that breaks the mold for everything. I have seen some people do crazy things with conditional operators just to show their "knowledge" of them off.
|
|
|
|
|
Craziest code example I have seen for a while.
I have never heard of a country, organization or anything else were only 18-year-olds, noone else whether younger or older, can vote.
And I have never seen the conditional statement used to select between alternatives 'true' and 'false'. I hope the compiler is smart enough to ignore the conditional and generate code as if you had written
userCanVote = userAge == 18;
|
|
|
|
|
Member 7989122 wrote: I have never heard of a country, organization or anything else were only 18-year-olds, noone else whether younger or older, can vote.
Kevin
|
|
|
|
|
I admin, recently the CodeLen suggest a code piece that I had to do a double look.
return foo ? (foo=new Foo()); or
if (obj is Foo foo) foo.bar();
It's shorter.
|
|
|
|
|
When omitted, it's usually by deletion.
They get popped in by habit - and even if only one statement follows there's no reason to remove them. It's to create a visual convention - you (at least my) eyes have everything grouped for them, indent levels almost always co-re-inforeced with something like:
if(the beginning) {
some_silly_possibility();
}
There are conventions (my own, obviously) for else's, too. Similar for all code-blocks. Even when source is well out of sight you know the beginning and the end (and which/where to insert/delete code and/or braces).
Even if not via some (so-called) standard, it is visually obvious to any onlooker, and that's the real point.
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
