I'm historically a braces-on-their-own-line guy, so getting used to the strict enforcement of the other style was a pain for me
Wait, what?
Wait, what?
void func()
{
}
void func() {
}
Go style is enforced mechanically with gofmt (http://weekly.golang.org/cmd/gofmt/), anyway, so one typically drops the pretension of these kinds of style quibbles. It is more important to have one consistent style than to make everyone happy. The gofmt style forced me to change several of my own habits, but it was definitely worth it for my code to look like everyone else's. I've never encountered a Go programmer who hasn't become grateful for gofmt, in the end.
Anyway, in that case I imagine we'll see a Go preprocessor that takes all the line-initial braces and moves them up a break before sending code to the compiler. People get pretty worked up about this stuff.
It's Python code and I find it uglier than some fairly large C++ project I used to work on.
Anyway, I wish there was a gofmt in Python because at least, I'd drop all hopes of forging my own rules (silly junkies) and some basic clarity would be forced into our codebase.
I know there are beautifiers but when such things are enforced and not negotiable, it's just so much simpler and people just stop caring as well.
I've always argued that if your team can't bother to even indent code properly than you have much bigger problems than any language formatting rules can solve.
We decided to make our build system run PEP over the code, resulting in a failure if PEP didn't pass.
It annoyed the hell out of him, but we quickly got the formatting up to a better standard.
I strongly believe that code should look like a screenplay, not a novel. More white space, in other words, is rarely a bad thing. Inline braces decrease white space and make unfamiliar code harder to scan, so to me they're Not Good.
Also wow, I didn't know it was even possible to write Python without spaces. Are we talking no spaces in arguments, like
def func(arg1,arg2):
print "Indented"
return
def func(arg1,arg2):
print "Not indented"
return
def func(arg1,arg2):
i=other_stuff(1,2,3,4,56,43,234+4*3)
return iThe answer usually given is faster compile times and the removal of semicolons from the language. I don't know the details, but someone new complains about it on the mailing list fairly frequently.
Also having a tool enforced brace style is just plain practical. Less silly arguments/bikeshedding.
I was also a brace on its own line kinda guy, but between javascript and go, I've gotten over it.
Not that I have any experience with that...
a := 1 vs a = 1
With '=' I can "hyperthread" my typing. While I'm finishing the LHS and pressing space I can move my right hand to press '=', while keeping my left hand thumb in place to press the space bar for the right side.
With ':=' I have to stop everything to press shift with my left hand, then press ':', then release shift and press '='. It's very inefficient for something that happens often.
In the long run I'd say multiple assignment probably saves you more time writing declarations than an extra key-stroke would cost you.
My main gripe with := vs = is that as I change my code, an existing := may suddenly become invalid, meaning I have to go back and change it when compilation fails, or vice versa.
As someone who has been stuck writing JavaScript for Yahoo Widgets (Vizio Connected TV) over the past month, my appreciation for the compiler errors you get in static languages has grown tremendously. Previously I had taken them too much for granted.
if a == b {}
var a int
a = 42
a := 42
So, in other words, it's Amateur Hour. All righty, then.
/backs toward door, reaches for doorknob, still smiling and nodding
ROFL. I challenge you to find documentation for the C language or any other language commonly used in production where they speculate that they might wake up one day and change sizeof(int) on an existing platform.
"Fantastically dumb," indeed.
You seem very ignorant, please learn and stop the FUD.
Yeah, that must be it.
As far as the documentation for the C langauge where they speculate that it's not defined, just given a minimum bound: here you go: Their implementation-defined values shall be equal or greater in magnitude (absolute value) to those shown, with the same sign (C99 spec, section 5.2.4.2.1)
It also allows sign-magnitude integers (complement 1) in addition to complement 2 (C99 spec, section 6.2.6.2)
It also doesn't define the number of bits in a byte (C99 spec, section 3.6 p2)
No, C doesn't define sizeof(int). It is implementation defined. But you don't change it once you implement it in a given development environment... not if you want people to create and maintain production code with your tools. You don't speculate that one day you might want to change sizeof(int). It's just not something you do if you want to be taken seriously.
Is anyone in this thread over the age of 16?
If you write production C code that depends on anything other than the minimum sizes defined in limits.h, your code is buggy.
For example, sort.Interface:
package sort
// A type, typically a collection, that satisfies sort.Interface can be
// sorted by the routines in this package. The methods require that the
// elements of the collection be enumerated by an integer index.
type Interface interface {
// Len is the number of elements in the collection.
Len() int
// Less returns whether the element with index i should sort
// before the element with index j.
Less(i, j int) bool
// Swap swaps the elements with indexes i and j.
Swap(i, j int)
}
void func() {
}