Tag Info

Hot answers tagged

626

This notion of Single Entry, Single Exit (SESE) comes from languages with explicit resource management, like C and assembly. In C, code like this will leak resources: void f() { resource res = acquire_resource(); // think malloc() if( f1(res) ) return; // leaks res f2(res); release_resource(res); // think free() } In such languages, you ...


438

You can thank the IBM punch card for this limit - it had 80 columns:


394

"Single Entry, Single Exit" was written when most programming was done in assembly language, FORTRAN, or COBOL. It has been widely misinterpreted, because modern languages do not support the practices Dijkstra was warning against. "Single Entry" meant "do not create alternate entry points for functions". In assembly language, of course, it is possible to ...


176

This is a "standards smell" to me. Whenever I see coding standards with specific limits in them, I worry. You almost always run into a case where a method needs to be bigger than the standard allows (whether it's line length/count, number of variables, number of exit points, etc). Standards should be more like guidelines, and allow sufficient leeway for ...


151

Hehe, oh Mr Brown, if only I could persuade all the developers I meet to keep their functions as small as this, believe me, the software world would be a better place! 1) Your code readability increases ten fold. 2) So easy to figure out the process of your code because of the readability. 3) DRY - Don't Repeat Yourself - You're conforming to this very ...


144

Your friend is wrong, and very few programmers would agree with him. You should write comments whenever and wherever you feel they best aid understanding.


137

i and j have typically been used as subscripts in quite a bit of math for quite some time (e.g., even in papers that predate higher-level languages, you frequently see things like "Xi,j", especially in things like a summation). When they designed Fortran, they (apparently) decided to allow the same, so all variables starting with "I" through "N" default to ...


131

Had a professor once who demanded we have at least one comment for each line of code. //Set x to 3 var x = 3; //if x is greater than 2 if(x>2){ //Print x Print(x); } It was pretty ridiculous.


126

It's only redundant code, not life or death. However.... If it's happening a lot, it could be a problem with how someBool is being named. A good name can go a long way towards eliminating the need for the ==true if(IsSomeCondition) or if(hasCondition) or if(somethingExists) for example.


124

Because its orginal intention (see http://www.joelonsoftware.com/articles/Wrong.html and http://fplanque.net/Blog/devblog/2005/05/11/hungarian_notation_on_steroids) has been misunderstood and it has been (ab)used to help people remember what type a variable is when the language they use is not statically typed. In any statically typed language you do not ...


121

As oded mentioned, this common coding standard is a result of the IBM's 1928 80 column punched card format, since many coding standards date back to a time when programs were written on punch cards, one card/line at a time, and even the transition to wider screens didn't alter the fact that code gets harder to read the wider it becomes. From the wikipedia ...


116

The sole purpose of software abstractions is to hide functional details. Were it not for those abstractions, it would not be possible to progress beyond a certain point in computing, because systems would simply collapse under the weight of their own complexity. Human brains can only comprehend so much information at once. Consider what happens when you ...


107

Writing code is easy. Reading code is hard. You write code once. It lives for years, people read it a hundred times. Optimize code for reading, not for writing.


103

Our company (C#) coding standard called for extensive use of #REGIONs (for those who don't know, it marks blocks of source code that will be collapsted to a single line in Visual Studio). As a consequence, you always opened what seemed to be a nicely structured class, only to find piles and piles of garbage swept under deeply nested rugs of #REGION ...


97

This may ruffle a few feathers, but standards that mandate templated block comments at the top of each method always bug the crap out of me. 1) They are always out of date since they are too far from the code that does the actual work to notice when you are updating things. Bad comments are worse than no comments. 2) They often just repeat information ...


95

Comments should be written for human beings to understand. When human beings communicate, we typically use "I", "we", "you", etc. When someone is trying to understand some code, there are two or more actors: the person reading it, and the original author of the code. Saying "we" is fine. Unless by 'professional', you mean 'robot-like'.


89

Strictly speaking, no you don't, YAGNI applies. That said, the time you'll spend creating the interface is minimal, especially if you have a handy code generation tool doing most of the job for you. If you are uncertain on whether you are going to need the interface of or not, I'd say it's better to err on the side of towards supporting the definition of an ...


86

The reason the software uses those names is because the datasheets use those names. Since code at that level is very difficult to understand without the datasheet anyway, making variable names you can't search is extremely unhelpful. That brings up the question of why datasheets use short names. That's probably because you often need to present the names ...


83

Ignore your friend. Comment as needed. But endeavor to make your code self-explanatory, so that comments aren't needed. Remember that your computer isn't executing comments, and so it's easy for comments to get out of sync with what's actually going on. I tend to use a block of comment to explain a particularly tricky bit of logic, that would otherwise take ...


81

In one job we were forced to use some weird form of Hungarian notation in the database. I can't remember the details, but from memory, each field name had to contain: No vowels All uppercase letters A reference to the table A data type indicator A data length A nullable indicator For example, the column holding a person's first name might be called: ...


80

I agree with your code reviewers, but with an asterisk. Each statement that you write in your code is a technical liability -- it's a potential failure point. If you write a method with 10 statements and your coworker writes one that achieves the same functionality with 5 statements, his is likely to be 'better' as measured by likelihood of issues (there are ...


77

It is usually a good idea to split stuff into little methods. But the important thing is to split things where it make sense. If it doesn't make sense to split, then don't split. This is often the case for some procedures or GUI code. Steve McConnell stated in Code Complete that you aren't always more productive when using short methods. If you split when ...


76

I stopped using this pattern a long time ago, for a very simple reason; maintenance cost. Several times I found that I had some function say frobnicate(something, forwards_flag) which was called many times in my code, and needed to locate all the places in the code where the value false was passed as the value of forwards_flag. You can't easily search ...


72

I entirely agree with your opinion, and believe it isn't all that subjective. The name of a variable is only as relevant as its scope. There is no point in endless discussions about a name of a variable which will only be read by a person reading that particular small scoped piece of code. On the other hand, class names and member names need to clearly ...


72

Those "change-logs" embedded in the code are particularly naff. They just show up as yet another difference when you diff revisions, and one that you don't really care about. Trust your VCS - most have a "blame" feature which will show you very quickly who changed what. Of course the really horrible thing was that feature of "old-time" VCS's where you ...


71

When I see someBool == true, I can't help but feel like the programmer hasn't internalized the idea of evaluation, which is a pretty fundamental deficiency. However, my perspective is skewed because I spent several summers in college teaching programming to kids, who frequently wrote expressions like this because they genuinely hadn't mastered the mental ...


70

A co-worker and I had a similar problem on our team when we first joined (I joined the team first, he joined about a year later). There were no real code standards. We're a MS shop, and even the MS coding standards weren't used. We decided to lead by example. We sat down together and drafted a document that had all of our standards: IDE standards, naming ...


67

I feel the code should read: PowerManager::PowerManager(IMsgSender* msgSender) : msgSender_(msgSender) { assert(msgSender); } void PowerManager::SignalShutdown() { assert(msgSender_); msgSender_->sendMsg("shutdown()"); } This is actually better than guarding the NULL, because it makes it very clear that the function should never be ...


65

The problem with measurements, no matter how well intended they are, is the very act of measuring the item makes it important, and the corollary, the act of not measuring an item makes it unimportant. It is absolutely essential to measure what is important, and not measure what is unimportant. Measuring SLOC (Which is effectively what your reviews are ...


63

When most people say "Hungarian Notation" they're actually talking about "Systems Hungarian". Systems Hungarian is completely useless and should be avoided. There is no need to encode the type of the variable in it's name. However, Systems Hungarian is actually a misunderstanding of the original, "real" Hungarian: Apps Hungarian. In Apps Hungarian, you ...



Only top voted, non community-wiki answers of a minimum length are eligible