approach to fighting spam. Your idea will not work. Here is why it won't work. (One or more of the following may apply to your particular idea, and it may have other flaws which used to vary from state to state before a bad federal law was passed.)
( ) Spammers can easily use it to harvest email addresses
(x) Mailing lists and other legitimate email uses would be affected
( ) No one will be able to find the guy or collect the money
( ) It is defenseless against brute force attacks
( ) It will stop spam for two weeks and then we'll be stuck with it
( ) Users of email will not put up with it
(x) Microsoft will not put up with it
( ) The police will not put up with it, anywhere other than Russia
( ) Requires too much cooperation from spammers
(x) Requires immediate total cooperation from everybody at once
( ) Many email users cannot afford to lose business or alienate potential employers
( ) Spammers don't care about invalid addresses in their lists
( ) Anyone could anonymously destroy anyone else's career or business
Specifically, your plan fails to account for
( ) Laws expressly prohibiting it
( ) Lack of centrally controlling authority for email
( ) Open relays in foreign countries
( ) Ease of searching tiny alphanumeric address space of all email addresses
( ) Asshats
( ) Jurisdictional problems
( ) Unpopularity of weird new taxes
( ) Public reluctance to accept weird new forms of money
(x) Huge existing software investment in SMTP
( ) Susceptibility of protocols other than SMTP to attack
( ) Willingness of users to install OS patches received by email
( ) Armies of worm riddled broadband-connected Windows boxes
( ) Eternal arms race involved in all filtering approaches
( ) Extreme profitability of spam
( ) Joe jobs and/or identity theft
( ) Technically illiterate politicians
( ) Extreme stupidity on the part of people who do business with spammers
( ) Dishonesty on the part of spammers themselves
( ) Bandwidth costs that are unaffected by client filtering
( ) Outlook
and the following philosophical objections may also apply:
( ) Ideas similar to yours are easy to come up with, yet none have ever
been shown practical
( ) Any scheme based on opt-out is unacceptable
( ) SMTP headers should not be the subject of legislation
( ) Blacklists suck
( ) Whitelists suck
( ) We should be able to talk about Viagra without being censored
( ) Countermeasures should not involve wire fraud or credit card fraud
( ) Countermeasures should not involve sabotage of public networks
(x) Countermeasures must work if phased in gradually
( ) Sending email should be free
( ) Why should we have to trust you and your servers?
( ) Incompatiblity with open source or open source licenses
( ) Feel-good measures do nothing to solve the problem
( ) Temporary/one-time email addresses are cumbersome
( ) I don't want the government reading my email
Furthermore, this is what I think about you:
(x) Sorry dude, but I don't think it would work.
( ) This is a stupid idea, and you're a stupid person for suggesting it.
( ) Nice try, asshole! I'm going to find out where you live and burn your
house down!
You are right that stepping through a deep call stack can be irritating. That's why rather than do frequent debugging on the whole system / class / whatever, we try to do unit testing where possible and debug as little fragments of code as possible. Having quite short methods makes that nearly trivial most of the time. It isn't always possible so yes, at times we have to bare with the bad.
Maybe the things I described here seem idealistic but in fact the best thing about them is that most of the deal can (and should) be automated. Even very complicated refactoring can be done by Eclipse or NetBeans, and while you must be careful (these tools are not perfect), they can do amazing things in seconds.
We also hate formal idealistic approaches to problem solving which take too much time. But that's a completely different story. Dare to ask Slashdot?;)
* similarly: set a file length limit (e.g. 1000 lines should be enough for everybody)
- it is a stupid practice to set artificial standards on thing like file length. It didn't make sense during vi time, nor does it make sense today, when any decent IDE can hide/display file outlines, sections of code, comment blocks etc.
No, it's not stupid because it has nothing to do with the ability to find what you're looking for by using Search/Replace, code folding, outlines, etc.
However, this has to do with informing you that the size of your compilation unit probably means that you could use a little Gang of Four treatment or remind yourself how that useful thing called inheritance worked.
same applies to any formatting basically, any IDE can reformat a source file to your liking. ( I only use tabs and always reformat code from spaces with an IDE, I hate spaces, you see. But if you want your spaces format it back with your IDE, or is that too hard?)
If you have programmers smart enough to understand that code formatting is not a religion, and you pay them enough for their time to be of really significant cost, then you wouldn't want to let them reformat code back and forth and waste their time on it. And as experience shows, no-one really cries about it.
same with the mandatory number of parameters - by specifying this you just provide justification for moron programmers to pass around lists/hashtables of parameters where not needed, thus hiding real method interfaces.
That's a conjecture. Our experience shows none of your worries happen in real life. What happens instead is that the mandatory number of parameters makes the developers refactor their code properly instead of adding "just another small parameter" when a need arises.
* you can also constraint the number of returns from methods (we found it to be very useful to set this to 1, using a result variable everywhere else - it's far easier to get hold of the code flow then)
- another silly constraint. Sometimes it makes sense to stop processing and exit without having anything else to do within a method, if this is not allowed the method will become more cumbersome by adding unnecessary control flow structures. You are complicating the code where it needs not be complicated.
Automatically forcing 'final' on items may lead to bugs if a declaration is really not final, for example if the object is populated by reflection at some point.
You're right about the fast and unequivocal returns when some initial assumption is not met (like a parameter is null or a database connection is down). Then it's useful to have those.
However, most of the time (and I really mean MOST OF the time) one return is what it should be. Marking fields final is as well, it enables compile-time optimizations, won't let you do stupid things like overwriting an internal state collection with another one, etc. Populated by reflection... really? How many times did you do that? Primo, this is a very special case. Secundo, in Java you can change the field state by reflection regardless whether fields are "final" or not.
* we also constraint the if depth and boolean expression complexity to manage the cyclomatic complexity - also for easier reading
- then you are doing this wrong as well. Forcing a particular depth of cycles/conditions is all great, except it does not provide a context for the reason of this action. I prefer to ask the developers to think in terms of business functionality. If loops and conditions are nested too deeply I ask to think for a reason why this may really be hiding a separate business function that even may be reused by another piece of code. Maybe it can be reused, maybe it can't, but the point is that in most cases deep enclosures are hiding some atomi
First let me just say I love Checkstyle. It is a very handy tool, and I highly recommend it. That being said I really disagree with some of the rules you've stated there.
And that's fine because they are not meant to be a global solution working in every case. In contrast, they were developed over the years and each of them can be easily backed up by examples and concrete reasoning. We had a group of rules we do not enforce nowadays because we found out that they weren't actually helpful. It's evolution, baby!
limit the length of the method to be visible on one 1280x1024 screen; if it's longer it's probably handy to extract smaller methods from it - which will be far more easy to read.
Repeat after me: The method will be as long as it needs to be. While I agree with this idea in principle (in my experience) it usually doesn't hold up in a live environment. If a method can be easily broken into separate methods, great. If not, so be it. Sometimes things are complicated enough without having to jump all around the file finding particular methods.
Of course, there is a small percentage of methods that cannot be easily separated. In fact, there are very few of them. All others can and should be refactored, if they are too long to read them without scrolling (that is usually ~70 LOC).
You say that many short methods can make browsing the compilation unit harder. I disagree since when you read new code (e.g. written by someone else or written by yourself a long time ago), it's very easy to grab the meaning of what a public API method actually does if it doesn't do every low-level thing on it's own but delegates it to methods like "createProjectDirectoryStructure(...)", "for (File file : directory) { addFileContentsToSearchIndex(file); }", etc. etc.
similarly: set a file length limit (e.g. 1000 lines should be enough for everybody)
Same argument as above, but at the project level instead of the class/file level.
In our view, a vast majority of compilation units that are longer than 1000 lines screams for refactoring using the latest discoveries of the software industry called inheritance and design patterns. Usually a class ends up being over a thousand lines where refactoring wasn't done at the package/project level for a long time or the developer (yes, there can be more than one in a particular project) is not familiar with a design pattern that is just about the right solution for the fatness of the class.
an upper limit on the allowed number of method parameters seems to be a good idea as well
If you have to enforce a rule like this chances are you have bigger problems than just correctly formatting your code. This is more of a design issue than anything else, and anyone who is generating code with method calls that take ungodly amounts of parameters needs to be straightened out rather quickly.
Sure, this is a design issue. It can arise after refactoring very old code, or when a previously unknown requirement is stated by the customer, or when you want to be compatible with some esoteric environment where the previous default behaviour wasn't enough.
It's easier for people to just add another parameter and the hell with it. Remember that it doesn't have to be you who write the code. Note that even your code can later be edited by someone else. In time, this kind of "one small parameter more won't harm" change gets the code to a state where it's really hard to read and tends to be less performant. It's more of a watchguard for the things to come, not a guard for up-front stupid developers.
a major one: Checkstyle can warn if it discovers a typical coding problem (of course this has some false positives but better to be on the safe side): double checked locking, lack of hash
Even here you see why people hate coding standards.
avoid star, redundant and unused imports
This only impacts build time. Not worth the time and hassle of importing every class individually for saving an additional 90 seconds on the rare occasion you do a complete rebuild.
The point of avoiding stars, redundant and unused imports is to enable readers of a particular class to easily see the dependencies of this compilation unit. When you have an arbitrary nonsense dependency which is not used, and your class has a couple of hundreds of lines of code - the reader will have trouble finding this fact. Have in mind that he/she could read your code by literally printing it out (many people still hate reading and inspecting things on CRT/LCD monitors).
Your point seems to be that it's better to import the whole classpath and do not have to think about it. But in fact, when you're coding using Eclipse or NetBeans, the imports are cleaned automatically for you.
enforce the usage of braces everywhere (e.g. disallow if (something) action; ): no misformatting will hide a trivial but dangerous bug
Stupid, forcing braces makes some code more unreadable. Situations where it's inappropriate to omit them can be caught during code review.
Seems to me you like to manually do things which can be automated. Having obligatory braces really reduces the percentage of problems like "Did you mean both lines should be in the else clause?" "Heck, I don't remember - let's waste time on it and find out." or "Sorry, I really thought there were braces where I put my extra line while refactoring..." See, we've been here before and this simple rule solved all these things.
The other thing I disagree with is that braces make code unreadable. In fact it's pretty much the opposite, if you use any reasonable formatting style while coding. Making braces obligatory makes the code very predictable.
Plus, just to repeat my mantra again: putting missing braces in if / else clauses can be automated in IDEs like Eclipse or NetBeans.
Also found I prefix in.NET really bad pracitce for marking interfaces like ICollection, what about when You decide turn interface to abstract class?..
Well. The whole point of having interfaces is allowing the implementation of a certain method set to the world, which later can be used in your APIs using polymorphism. If you later decide to break the contract and make an interface a class, then probably a name change (made also automatically in tools like Eclipse or NetBeans) won't be any worse.
As for the Hungarian notation, the standard form is indeed worthless. But we tend to use simple maximum three letter abbreviations of Swing components, to know that we are taking the username from txtLogin and listening for pressing btnOK. Code is more often read than written and this quasi-Hungarian style actually works pretty well.
In fact, having interfaces named like "IPasswordProvider" is something very similar. It enables easy reading of your code and when you want to make a change, you instantly see that this type is an interface, therefore you cannot instantiate it directly, but you can implement this interface in any arbitrary class you may already have written, etc. Plus, Sun coding standards encourage you to name interfaces in a passive adjective way like "Serializable", "Comparable", etc. To comply with this format is not very natural for interfaces like "IPasswordProvider" or "IModelContext".
If you are using your computer right, it does not only enable you to do things, it does the boring things for you, automatically.
Checkstyle is one of the tools in a company toolkit that is often overlooked but in fact VERY handy. It enables you to define a ruleset for your source code, finding stuff which is incompatible with the coding practice in your company/team/project/whatever. Moreover, you can stick it into Eclipse using the free Eclipse-CS plugin, so it will automagically mark the places which need to be change. Last but not least, you can put Checkstyle as an Ant task in your building environment (and in your continous integration toolkit) so commited code that does not conform certain standards does not build.
As for the rules themselves, we've found these to be the most successful:
limit the length of the method to be visible on one 1280x1024 screen; if it's longer it's probably handy to extract smaller methods from it - which will be far more easy to read
similarly: set a file length limit (e.g. 1000 lines should be enough for everybody)
an upper limit on the allowed number of method parameters seems to be a good idea as well
ensure that new code is commented by marking structures which could be javadoced but aren't
any naming and formatting convention is better than no convention; Checkstyle can use regular expressions to validate type, variable and other names. It can also check for whitespace constraints, new lines, etc.
avoid star, redundant and unused imports
enforce or forbid the usage of the tabulator character to have all code clean no matter where you open it
warn on redundant modifiers
enforce the usage of braces everywhere (e.g. disallow if (something) action; ): no misformatting will hide a trivial but dangerous bug
a major one: Checkstyle can warn if it discovers a typical coding problem (of course this has some false positives but better to be on the safe side): double checked locking, lack of hashcode when overriding equals, switch fallthroughs, illegal catches and throws, lack of super.clone() or super.finalize(), etc.
you can also constraint the number of returns from methods (we found it to be very useful to set this to 1, using a result variable everywhere else - it's far easier to get hold of the code flow then)
we also constraint the if depth and boolean expression complexity to manage the cyclomatic complexity - also for easier reading
it's useful to make Eclipse clean up your code on every save: to add "final" where it can, to fix imports, format the code to the specified form, etc.
Of course, we let developers to add suppresions for the 1% of false positives. In fact, there are very few suppresion rules set.
I was in love with Opera since 9.0 and used it happily over the years. But Opera 9.5 is garbage. I reported to them (twice) a MAJOR Unicode rendering bug that appeared on Mac OS X with 9.5 alpha and it hadn't been touched since. Nobody even bothered to contact me at all.
See here: http://www.langa.pl/operabug/
Yes, Apple did a poor job here but it's in fact not Mac Customers=Stupid, it's rather Beta Users Wanting Production Quality=Stupid. Usually I even go saying Version 1.0 Users Wanting Production Quality=Stupid...
I suppose you wrote this using another Mac (i.e. not MB Air). The superdrive for MacBook Air won't work with your hardware because the USB port in the MacBook Air is additionally powered.
Yeah.. we pesky non-native speakers always bump into things like that. I guess the distance between "I understand what you're saying" and "I understand what you mean" is longer than it seems.
I wonder how many of you feel as I do right now: "I thought about implementing something like this but I didn't find that idea to be significant enough... but if I did... I WOULD BE ON SLASHDOT NOW."
What a bummer.
Re:Performance, anyone?
on
Lisp and Ruby
·
· Score: 1
Yep. It's a bare AST representation after all. Thus it can be even faster than C in some algorithms. My initial post is kind of misstated (I'm not a native speaker). Check my other responses in this thread, I clarified that out.
Re:Performance, anyone?
on
Lisp and Ruby
·
· Score: 1
Actually the first link should have been this but I guess you get what I mean anyway.
Re:Performance, anyone?
on
Lisp and Ruby
·
· Score: 1
I know, I know... I guess I should be more careful with words (I'm not a native speaker).
Slashdot Mirror
The same technology is used even in Poland, which is still seen by the western world as a "developing country". By the way, see this.
Your post advocates a
(x) technical
( ) legislative
( ) market-based
( ) vigilante
approach to fighting spam. Your idea will not work. Here is why it won't work. (One or more of the following may apply to your particular idea, and it may have other flaws which used to vary from state to state before a bad federal law was passed.)
( ) Spammers can easily use it to harvest email addresses
(x) Mailing lists and other legitimate email uses would be affected
( ) No one will be able to find the guy or collect the money
( ) It is defenseless against brute force attacks
( ) It will stop spam for two weeks and then we'll be stuck with it
( ) Users of email will not put up with it
(x) Microsoft will not put up with it
( ) The police will not put up with it, anywhere other than Russia
( ) Requires too much cooperation from spammers
(x) Requires immediate total cooperation from everybody at once
( ) Many email users cannot afford to lose business or alienate potential employers
( ) Spammers don't care about invalid addresses in their lists
( ) Anyone could anonymously destroy anyone else's career or business
Specifically, your plan fails to account for
( ) Laws expressly prohibiting it
( ) Lack of centrally controlling authority for email
( ) Open relays in foreign countries
( ) Ease of searching tiny alphanumeric address space of all email addresses
( ) Asshats
( ) Jurisdictional problems
( ) Unpopularity of weird new taxes
( ) Public reluctance to accept weird new forms of money
(x) Huge existing software investment in SMTP
( ) Susceptibility of protocols other than SMTP to attack
( ) Willingness of users to install OS patches received by email
( ) Armies of worm riddled broadband-connected Windows boxes
( ) Eternal arms race involved in all filtering approaches
( ) Extreme profitability of spam
( ) Joe jobs and/or identity theft
( ) Technically illiterate politicians
( ) Extreme stupidity on the part of people who do business with spammers
( ) Dishonesty on the part of spammers themselves
( ) Bandwidth costs that are unaffected by client filtering
( ) Outlook
and the following philosophical objections may also apply:
( ) Ideas similar to yours are easy to come up with, yet none have ever been shown practical
( ) Any scheme based on opt-out is unacceptable
( ) SMTP headers should not be the subject of legislation
( ) Blacklists suck
( ) Whitelists suck
( ) We should be able to talk about Viagra without being censored
( ) Countermeasures should not involve wire fraud or credit card fraud
( ) Countermeasures should not involve sabotage of public networks
(x) Countermeasures must work if phased in gradually
( ) Sending email should be free
( ) Why should we have to trust you and your servers?
( ) Incompatiblity with open source or open source licenses
( ) Feel-good measures do nothing to solve the problem
( ) Temporary/one-time email addresses are cumbersome
( ) I don't want the government reading my email
Furthermore, this is what I think about you:
(x) Sorry dude, but I don't think it would work.
( ) This is a stupid idea, and you're a stupid person for suggesting it.
( ) Nice try, asshole! I'm going to find out where you live and burn your house down!
Thank you. Your post really made my day! And the operagost reply, too. That was taking this joke to a whole new level. AMAZING :D
Python is written in C, actually.
Where did you find that site? The comments are so dumb I'd say it's deliberate ;)
"Gentle passes of a butane blow torch" sounds like some serious goth poetry volume title ;)
What about this crazy idea:
Yeah, there even doesn't have to be a "???" step.
Except that they were not. The linked site says they were running on HP dv2000 with 2Gb RAM.
Surely you mean 2GB (or even more precisely 2GiB but nobody seems to actually use that one...)?
b is for bits and by using it for bytes you make baby Stallman cry.
Reference: http://en.wikipedia.org/wiki/Binary_prefix
So... it just finished booting up?
You are right that stepping through a deep call stack can be irritating. That's why rather than do frequent debugging on the whole system / class / whatever, we try to do unit testing where possible and debug as little fragments of code as possible. Having quite short methods makes that nearly trivial most of the time. It isn't always possible so yes, at times we have to bare with the bad.
Maybe the things I described here seem idealistic but in fact the best thing about them is that most of the deal can (and should) be automated. Even very complicated refactoring can be done by Eclipse or NetBeans, and while you must be careful (these tools are not perfect), they can do amazing things in seconds.
We also hate formal idealistic approaches to problem solving which take too much time. But that's a completely different story. Dare to ask Slashdot? ;)
That is the reason I used this tag as the first word ;)
* similarly: set a file length limit (e.g. 1000 lines should be enough for everybody)
- it is a stupid practice to set artificial standards on thing like file length. It didn't make sense during vi time, nor does it make sense today, when any decent IDE can hide/display file outlines, sections of code, comment blocks etc.
No, it's not stupid because it has nothing to do with the ability to find what you're looking for by using Search/Replace, code folding, outlines, etc.
However, this has to do with informing you that the size of your compilation unit probably means that you could use a little Gang of Four treatment or remind yourself how that useful thing called inheritance worked.
same applies to any formatting basically, any IDE can reformat a source file to your liking. ( I only use tabs and always reformat code from spaces with an IDE, I hate spaces, you see. But if you want your spaces format it back with your IDE, or is that too hard?)
If you have programmers smart enough to understand that code formatting is not a religion, and you pay them enough for their time to be of really significant cost, then you wouldn't want to let them reformat code back and forth and waste their time on it. And as experience shows, no-one really cries about it.
same with the mandatory number of parameters - by specifying this you just provide justification for moron programmers to pass around lists/hashtables of parameters where not needed, thus hiding real method interfaces.
That's a conjecture. Our experience shows none of your worries happen in real life. What happens instead is that the mandatory number of parameters makes the developers refactor their code properly instead of adding "just another small parameter" when a need arises.
* you can also constraint the number of returns from methods (we found it to be very useful to set this to 1, using a result variable everywhere else - it's far easier to get hold of the code flow then)
- another silly constraint. Sometimes it makes sense to stop processing and exit without having anything else to do within a method, if this is not allowed the method will become more cumbersome by adding unnecessary control flow structures. You are complicating the code where it needs not be complicated.
Automatically forcing 'final' on items may lead to bugs if a declaration is really not final, for example if the object is populated by reflection at some point.
You're right about the fast and unequivocal returns when some initial assumption is not met (like a parameter is null or a database connection is down). Then it's useful to have those.
However, most of the time (and I really mean MOST OF the time) one return is what it should be. Marking fields final is as well, it enables compile-time optimizations, won't let you do stupid things like overwriting an internal state collection with another one, etc. Populated by reflection... really? How many times did you do that? Primo, this is a very special case. Secundo, in Java you can change the field state by reflection regardless whether fields are "final" or not.
* we also constraint the if depth and boolean expression complexity to manage the cyclomatic complexity - also for easier reading
- then you are doing this wrong as well. Forcing a particular depth of cycles/conditions is all great, except it does not provide a context for the reason of this action. I prefer to ask the developers to think in terms of business functionality. If loops and conditions are nested too deeply I ask to think for a reason why this may really be hiding a separate business function that even may be reused by another piece of code. Maybe it can be reused, maybe it can't, but the point is that in most cases deep enclosures are hiding some atomi
First let me just say I love Checkstyle. It is a very handy tool, and I highly recommend it. That being said I really disagree with some of the rules you've stated there.
And that's fine because they are not meant to be a global solution working in every case. In contrast, they were developed over the years and each of them can be easily backed up by examples and concrete reasoning. We had a group of rules we do not enforce nowadays because we found out that they weren't actually helpful. It's evolution, baby!
Repeat after me: The method will be as long as it needs to be. While I agree with this idea in principle (in my experience) it usually doesn't hold up in a live environment. If a method can be easily broken into separate methods, great. If not, so be it. Sometimes things are complicated enough without having to jump all around the file finding particular methods.
Of course, there is a small percentage of methods that cannot be easily separated. In fact, there are very few of them. All others can and should be refactored, if they are too long to read them without scrolling (that is usually ~70 LOC).
You say that many short methods can make browsing the compilation unit harder. I disagree since when you read new code (e.g. written by someone else or written by yourself a long time ago), it's very easy to grab the meaning of what a public API method actually does if it doesn't do every low-level thing on it's own but delegates it to methods like "createProjectDirectoryStructure(...)", "for (File file : directory) { addFileContentsToSearchIndex(file); }", etc. etc.
Same argument as above, but at the project level instead of the class/file level.
In our view, a vast majority of compilation units that are longer than 1000 lines screams for refactoring using the latest discoveries of the software industry called inheritance and design patterns. Usually a class ends up being over a thousand lines where refactoring wasn't done at the package/project level for a long time or the developer (yes, there can be more than one in a particular project) is not familiar with a design pattern that is just about the right solution for the fatness of the class.
If you have to enforce a rule like this chances are you have bigger problems than just correctly formatting your code. This is more of a design issue than anything else, and anyone who is generating code with method calls that take ungodly amounts of parameters needs to be straightened out rather quickly.
Sure, this is a design issue. It can arise after refactoring very old code, or when a previously unknown requirement is stated by the customer, or when you want to be compatible with some esoteric environment where the previous default behaviour wasn't enough.
It's easier for people to just add another parameter and the hell with it. Remember that it doesn't have to be you who write the code. Note that even your code can later be edited by someone else. In time, this kind of "one small parameter more won't harm" change gets the code to a state where it's really hard to read and tends to be less performant. It's more of a watchguard for the things to come, not a guard for up-front stupid developers.
Even here you see why people hate coding standards.
This only impacts build time. Not worth the time and hassle of importing every class individually for saving an additional 90 seconds on the rare occasion you do a complete rebuild.
The point of avoiding stars, redundant and unused imports is to enable readers of a particular class to easily see the dependencies of this compilation unit. When you have an arbitrary nonsense dependency which is not used, and your class has a couple of hundreds of lines of code - the reader will have trouble finding this fact. Have in mind that he/she could read your code by literally printing it out (many people still hate reading and inspecting things on CRT/LCD monitors).
Your point seems to be that it's better to import the whole classpath and do not have to think about it. But in fact, when you're coding using Eclipse or NetBeans, the imports are cleaned automatically for you.
Stupid, forcing braces makes some code more unreadable. Situations where it's inappropriate to omit them can be caught during code review.
Seems to me you like to manually do things which can be automated. Having obligatory braces really reduces the percentage of problems like "Did you mean both lines should be in the else clause?" "Heck, I don't remember - let's waste time on it and find out." or "Sorry, I really thought there were braces where I put my extra line while refactoring..." See, we've been here before and this simple rule solved all these things.
The other thing I disagree with is that braces make code unreadable. In fact it's pretty much the opposite, if you use any reasonable formatting style while coding. Making braces obligatory makes the code very predictable.
Plus, just to repeat my mantra again: putting missing braces in if / else clauses can be automated in IDEs like Eclipse or NetBeans.
Also found I prefix in .NET really bad pracitce for marking interfaces like ICollection, what about when You decide turn interface to abstract class?..
Well. The whole point of having interfaces is allowing the implementation of a certain method set to the world, which later can be used in your APIs using polymorphism. If you later decide to break the contract and make an interface a class, then probably a name change (made also automatically in tools like Eclipse or NetBeans) won't be any worse.
As for the Hungarian notation, the standard form is indeed worthless. But we tend to use simple maximum three letter abbreviations of Swing components, to know that we are taking the username from txtLogin and listening for pressing btnOK. Code is more often read than written and this quasi-Hungarian style actually works pretty well.
In fact, having interfaces named like "IPasswordProvider" is something very similar. It enables easy reading of your code and when you want to make a change, you instantly see that this type is an interface, therefore you cannot instantiate it directly, but you can implement this interface in any arbitrary class you may already have written, etc. Plus, Sun coding standards encourage you to name interfaces in a passive adjective way like "Serializable", "Comparable", etc. To comply with this format is not very natural for interfaces like "IPasswordProvider" or "IModelContext".
If you are using your computer right, it does not only enable you to do things, it does the boring things for you, automatically.
Checkstyle is one of the tools in a company toolkit that is often overlooked but in fact VERY handy. It enables you to define a ruleset for your source code, finding stuff which is incompatible with the coding practice in your company/team/project/whatever. Moreover, you can stick it into Eclipse using the free Eclipse-CS plugin, so it will automagically mark the places which need to be change. Last but not least, you can put Checkstyle as an Ant task in your building environment (and in your continous integration toolkit) so commited code that does not conform certain standards does not build.
As for the rules themselves, we've found these to be the most successful:
Of course, we let developers to add suppresions for the 1% of false positives. In fact, there are very few suppresion rules set.
I was in love with Opera since 9.0 and used it happily over the years. But Opera 9.5 is garbage. I reported to them (twice) a MAJOR Unicode rendering bug that appeared on Mac OS X with 9.5 alpha and it hadn't been touched since. Nobody even bothered to contact me at all. See here: http://www.langa.pl/operabug/
Yes, Apple did a poor job here but it's in fact not Mac Customers=Stupid, it's rather Beta Users Wanting Production Quality=Stupid. Usually I even go saying Version 1.0 Users Wanting Production Quality=Stupid...
I suppose you wrote this using another Mac (i.e. not MB Air). The superdrive for MacBook Air won't work with your hardware because the USB port in the MacBook Air is additionally powered.
MacBook Air USB Details
Yeah.. we pesky non-native speakers always bump into things like that. I guess the distance between "I understand what you're saying" and "I understand what you mean" is longer than it seems.
Solving this problem using computers would surely skew the results, now wouldn't it?
I wonder how many of you feel as I do right now: "I thought about implementing something like this but I didn't find that idea to be significant enough... but if I did... I WOULD BE ON SLASHDOT NOW." What a bummer.
Yep. It's a bare AST representation after all. Thus it can be even faster than C in some algorithms. My initial post is kind of misstated (I'm not a native speaker). Check my other responses in this thread, I clarified that out.
Actually the first link should have been this but I guess you get what I mean anyway.
I know, I know... I guess I should be more careful with words (I'm not a native speaker).
Cheers.