|
As the feature said, a single statement. I don't usually put brace on single statement. I like to write tight code. Begin brace always hanging at the end of the compound control block with the matching ending brace align to the block controller. Most single statement under-control by iterator, getter, setter stay as a single line, if it is not running off the page. Use common sense. 
|
|
|
|
|
Single line statements, always use braces, braces on their own line, region to organise code, single space between methods, single space between objects in xaml. Ctrl E-D to apply consistent formatting, use SQL Prompt formatting for stored procs.
Consistent naming convention, camel case everything (Oracle with it's all caps makes me physically ill).
I AM analy retentive and my code is consistently formatted and laid out and bloody easy to read.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Mycroft Holmes wrote: nd bloody easy to read
Everybody (and his dog) finds the own code bloody easy to read. That proves nothing.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
I have automated as many of these issues as possible.
I type no more than I need, then press a shortcut key and all gets aligned and formatted as God intended.
|
|
|
|
|
Franc Morales wrote: type no more than I need
Very commendable! Then you enter your machine code directly? After all, there is not very much about hexadecimal one can write in a confusing way.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
Yes, mostly, unless the situation allows for the single statement to appear on the same line. Which may be most of the time, or half the time, some of the time, or rare as hen's teeth.
If you think 'goto' is evil, try writing an Assembly program without JMP.
|
|
|
|
|
How is "Yes, mostly" that different from "It depends on the situation"?
Well ... "Mostly" means most of the time, regardless of the situation it involves. You basicaly count all the times you did it against all the code you ever wrote in your life and see if it happens more thant 50%; if so, it is "Yes, mostly".
"It depends on the situation" implies that you analise the code to see if it's posible to keep it as a one-line-code, or if the situation (like a long single command would be ugly on one single line - for example) even though possible, would not be favorable to do it. If so, then it's "depends on the situation".
Lol ... systems analists analise everything, even texts on a survey. I think it means i have to much time on my hands, better get back to work! lol.
|
|
|
|
|
I think "Yes, mostly" is for those of us with problems speaking in absolutes I want to say "Yes, Always" but what if once 5 years ago I slapped together a quick one line if statement and left out curly braces. I would have been lying in the survey.
|
|
|
|
|
I use enclosing characters every time i can, braces always* (unless i forget some for any reason) and try to single line every piece of code i can, so this:
public class Test
{
protected int _x1;
protected int _x2;
public int X1
{
get
{
return _x1;
}
set
{
_x1 = value;
}
}
public int X2
{
get
{
return _x2;
}
set
{
_x2 = value;
}
}
public int Sum
{
get
{
return _x1 + _x2;
}
}
}
Becomes this:
public class Test
{
protected int _x1;
protected int _x2;
public int X1 { get { return this._x1; } set { this._x1 = value; } }
public int X2 { get { return this._x2; } set { this._x2 = value; } }
public int Sum { get { return (this._x1 + this._x2); } }
}
Aahhhh.... 10 times better! Also, always place the "this" element before calling variables/methods
|
|
|
|
|
public class Test
{
public int X1 { get; set; }
public int X2 { get; set; }
public int Sum => X1 + X2;
} 
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Yes! I use a lot of auto-assign properties as well, but thought would be better not to shrink the code that much ... i literally have classes that (either by inheriting other classes or just by their own simplicity) look like this:
public class Thin { public int ID { get; set; } }
public class UltraThin : Thin { public string Name { get; set; } }
public class OhMyGod : UltraThin { public ushort Age { get; set; } }
I'm so happy ... lol!
|
|
|
|
|
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.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
