If a firm is that afraid of changing anything about their code for fear of the whole thing collapsing, then they must not know anything about testing code, which means they pretty much don't have any business making it in the first place.
Some compilers get a bit weird about what order they want to execute things in a comma-separated statement. I think you're generally not supposed to assume things will happen in the order you wrote them, which kinda defeats the purpose of C being imperative programming.
(I might be wrong, but I think I remember reading that.)
Some things I tend to do that that I'm not quite convinced are good ideas, but I do them anyway:
// When things take multiple lines I try to line them up... space before '{' here class SpaceDog extends RegularDog implements AdaptedForSpace { // variable declarations lined up private String name; private CanineSpaceMission mission;
// a method like this... no space before brace when after a paren boolean bark(){ // control structures written the same as function calls (no space after if); // one-lining simple conditionals if(inThePresenceOfAtmosphere) return true;
if(Space.noOneCanHearYouBark()){ // and a try block like this... try { frivolouslyAlterPhysicalLaws(); } catch(NewtonianOutrageException e){ beSadButDoItQuietly(); return false; } // empty blocks without line break catch(PtolemianOutrageException ignored){} } produceIllogicalArf(); return true; }
// annoyingly verbose java getters and setters on one line if they're trivial public SpaceMission getMission(){ return mission; }
public void destroyEnemy(EarthCat earthCat){ // I do this sometimes, it lines up and the inside of the if block still indents once from the condition, // instead of indenting the second line further ahead and having the block un-indent if(EarthCat.inherentlyEvil() && earthCat.threatensCanineMission()) destroy(earthCat); } }
I'm not so sure about a lot of these habits... what do you think? Do you have any style habits you're not so sure of?
Agreed. I don't think it ever looks good to have an opening and closing brace on the same line (especially since you don't need the braces at all, unless you have multiple statements in there, which would make it even worse to read). Especially since the first thing I thought when I looked at that was, did he close the else block on the same line as its last statement? Then I saw the closing brace below and starting looking for a nested (multi-line) block, and then noticed the unnecessarily {}'s on the one line.
I think
if(something) do_something();
is just as good as (or better than)
if(something)
do_something();
for simple one-line conditionals, especially for things like
if(x > 0) return x;
// or to get a bit Java-ish if(bad_thing) throw new BadThingException();
but these are simple conditionals that are really clear in one line. If you're going to tack on any elses, be consistent in how you indent all the blocks, so
I think this is a bit more than just personal preference, if you have a list of alternatives they should all be indented equally so they get equal attention.
Those crazy long lines do seem to happen a lot in C, and C++ and Java too (new instance passed to new instance passed to new instance, maybe). Maybe it's just habit? It's not ever necessary, I don't think.
I like taking any chunks of logic that are secondary to a function's algorithm and giving them their own function, even if I'm not currently using it more than once. Unless you're developing for a platform with limited memory or a profiler tells you a function it taking too long, there's no reason this could be a bad thing. It can really help make code more self-documenting if you use more and smaller functions with clear names... you can afford the space to write out a longer, clear name if you're moving secondary logic to functions of their own.
Also, I'm a fan of splitting up long expressions (like in conditionals) over lots of lines and lining them in a nice way, it's clear and easy on the eyes. Same with a group of assignment statements at the start of a block, declaring a class's instance variables, etc.
Because.... because it's just too impractical to require an open source mouse! People need to be able to get things done!...except don't apply that logic when it comes to software, because then it's wrong. For some reason.;)
I see where you're coming from, copyright protects you in particular then by assuring people know that your songs are yours.... Unfortunately, I'm pretty sure that, say, Nirvana or RHCP or whoever people are looking for tabs on don't have the same problem. Once your songs are well-known no one's going to go into a coffee shop and pretend they wrote it. And the tabs on these sites are for well-known songs...
It really is just a matter of "does anyone care?" I guess.
You can't just copy it word-for-word. In other words, while the facts aren't copyrighted, their organization and expression in a fixed medium (the shop manual) is.
So shouldn't the fact that most of these (usually user-submitted) tabs on most tabs sites are either greatly simplified or completely wrong be their saving grace? I'd call it paraphrasing the work at best.
I wasn't so sure about the awesomebar when I read about it, but in practice I actually like it a lot.
What I did was turn off my history completely. If I want it to remember a page to "search intelligently" later on, I can star it so it goes in unsorted bookmarks, and tag it if I want. Being able to type "/." and have slashdot come up as a match is pretty nice.
I'd rather have it search intelligently through things I ask it to remember than search dumbly through everything I've visited since I last cleared my history.:)
Slashdot Mirror
If a firm is that afraid of changing anything about their code for fear of the whole thing collapsing, then they must not know anything about testing code, which means they pretty much don't have any business making it in the first place.
Some compilers get a bit weird about what order they want to execute things in a comma-separated statement. I think you're generally not supposed to assume things will happen in the order you wrote them, which kinda defeats the purpose of C being imperative programming.
(I might be wrong, but I think I remember reading that.)
Some things I tend to do that that I'm not quite convinced are good ideas, but I do them anyway:
// variable declarations lined up
// a method like this... no space before brace when after a paren
// control structures written the same as function calls (no space after if);
// one-lining simple conditionals
// and a try block like this...
// empty blocks without line break
// annoyingly verbose java getters and setters on one line if they're trivial
// I do this sometimes, it lines up and the inside of the if block still indents once from the condition,
// instead of indenting the second line further ahead and having the block un-indent
// When things take multiple lines I try to line them up... space before '{' here
class SpaceDog extends RegularDog
implements AdaptedForSpace {
private String name;
private CanineSpaceMission mission;
boolean bark(){
if(inThePresenceOfAtmosphere) return true;
if(Space.noOneCanHearYouBark()){
try {
frivolouslyAlterPhysicalLaws();
}
catch(NewtonianOutrageException e){
beSadButDoItQuietly();
return false;
}
catch(PtolemianOutrageException ignored){}
}
produceIllogicalArf();
return true;
}
public SpaceMission getMission(){ return mission; }
public void destroyEnemy(EarthCat earthCat){
if(EarthCat.inherentlyEvil()
&& earthCat.threatensCanineMission())
destroy(earthCat);
}
}
I'm not so sure about a lot of these habits... what do you think? Do you have any style habits you're not so sure of?
Agreed. I don't think it ever looks good to have an opening and closing brace on the same line (especially since you don't need the braces at all, unless you have multiple statements in there, which would make it even worse to read). Especially since the first thing I thought when I looked at that was, did he close the else block on the same line as its last statement? Then I saw the closing brace below and starting looking for a nested (multi-line) block, and then noticed the unnecessarily {}'s on the one line.
I think
is just as good as (or better than)
for simple one-line conditionals, especially for things like
but these are simple conditionals that are really clear in one line. If you're going to tack on any elses, be consistent in how you indent all the blocks, so
I think this is a bit more than just personal preference, if you have a list of alternatives they should all be indented equally so they get equal attention.
I like taking any chunks of logic that are secondary to a function's algorithm and giving them their own function, even if I'm not currently using it more than once. Unless you're developing for a platform with limited memory or a profiler tells you a function it taking too long, there's no reason this could be a bad thing. It can really help make code more self-documenting if you use more and smaller functions with clear names... you can afford the space to write out a longer, clear name if you're moving secondary logic to functions of their own.
Also, I'm a fan of splitting up long expressions (like in conditionals) over lots of lines and lining them in a nice way, it's clear and easy on the eyes. Same with a group of assignment statements at the start of a block, declaring a class's instance variables, etc.
I find it really odd that I haven't seen any mention of "In Soviet Russia, martian moon probes you"... or something to that effect.
If Russia had a dollar for every time that's been posted on /., it'd have itself a free Phobos-Grunt.
hax hax hax hax maphack n00b hax
(what goes through my mind when I think about open source console games online)
Because.... because it's just too impractical to require an open source mouse! People need to be able to get things done! ...except don't apply that logic when it comes to software, because then it's wrong. For some reason. ;)
You must be new here.
I lol'd.
Flash drives offer an even neater version of that, whenever they get big enough and cheap enough... no moving parts is a plus.
I see where you're coming from, copyright protects you in particular then by assuring people know that your songs are yours.... Unfortunately, I'm pretty sure that, say, Nirvana or RHCP or whoever people are looking for tabs on don't have the same problem. Once your songs are well-known no one's going to go into a coffee shop and pretend they wrote it. And the tabs on these sites are for well-known songs... It really is just a matter of "does anyone care?" I guess.
You can't just copy it word-for-word. In other words, while the facts aren't copyrighted, their organization and expression in a fixed medium (the shop manual) is.
So shouldn't the fact that most of these (usually user-submitted) tabs on most tabs sites are either greatly simplified or completely wrong be their saving grace? I'd call it paraphrasing the work at best.
Invisble?! Bow down... wait, what does that have to do with grammar?
I wasn't so sure about the awesomebar when I read about it, but in practice I actually like it a lot. What I did was turn off my history completely. If I want it to remember a page to "search intelligently" later on, I can star it so it goes in unsorted bookmarks, and tag it if I want. Being able to type "/." and have slashdot come up as a match is pretty nice. I'd rather have it search intelligently through things I ask it to remember than search dumbly through everything I've visited since I last cleared my history. :)
You must use facebook a lot.