Comments on: Coding For Readability http://www.red-sweater.com/blog/316/coding-for-readability Mac & Technology Writings by Daniel Jalkut Thu, 28 Aug 2008 20:37:17 +0000 http://wordpress.org/?v=2.6 By: macFanDave http://www.red-sweater.com/blog/316/coding-for-readability#comment-81400 macFanDave Mon, 09 Apr 2007 12:38:08 +0000 http://www.red-sweater.com/blog/316/coding-for-readability#comment-81400 Daniel, There are not very many people who are smarter than you ;-). You probably mean "people who have studied international trade more thoroughly than you have." Daniel,

There are not very many people who are smarter than you ;-). You probably mean “people who have studied international trade more thoroughly than you have.”

]]> By: Daniel Jalkut http://www.red-sweater.com/blog/316/coding-for-readability#comment-80953 Daniel Jalkut Sun, 08 Apr 2007 16:12:49 +0000 http://www.red-sweater.com/blog/316/coding-for-readability#comment-80953 Thanks for clarifying your points. I agree that globalization is a tricky subject and has a lot of implications that should be dealt with by people smarter than myself. Thanks for clarifying your points. I agree that globalization is a tricky subject and has a lot of implications that should be dealt with by people smarter than myself.

]]> By: macFanDave http://www.red-sweater.com/blog/316/coding-for-readability#comment-80951 macFanDave Sun, 08 Apr 2007 16:09:47 +0000 http://www.red-sweater.com/blog/316/coding-for-readability#comment-80951 Daniel, I apologize for the misunderstanding, but my "eff them" was directed at my greedy, treacherous corporate overlords, not at fellow developers overseas. Frankly, when I get to the point where I can outsource myself, it will be time to go anyways. The code base I work on is far from that point. I work for a manufacturer that requires customization on a per-piece basis (our product sells for $20,00 to > $100,000 a pop so customer demands for bells and whistles are justifiably honored.) The problem is that product engineering is unable or unwilling to give us their methodology unequivocally. It is unclear whether it is stupidity, laziness, or a turf battle that prevents them from letting us automate some of their daily tedium, but it provides us with endless opportunities to guess how they do their work and to respond to their fickle demands. They are hardly a group that has defined its problem well enough to engage outside contractors (local or global). For example, we had a New England firm bid on a project for about 7-10 times an average engineer's salary and wanted 15 months after receiving the complete spec. Well, another guy and I did it in-house in 9 months, and through weekly meetings with engineering, the spec constantly changed. The point is that our customer is so fickle, their efforts to engage outside contractors are doomed to failure, no matter where they are located. Globalization where capital and goods can flow freely, but labor cannot is disasterous for all but the elite. Engaging in international trade must be done soberly and not under the rubric of deceptive slogans like "free trade." Daniel,

I apologize for the misunderstanding, but my “eff them” was directed at my greedy, treacherous corporate overlords, not at fellow developers overseas.

Frankly, when I get to the point where I can outsource myself, it will be time to go anyways. The code base I work on is far from that point. I work for a manufacturer that requires customization on a per-piece basis (our product sells for $20,00 to > $100,000 a pop so customer demands for bells and whistles are justifiably honored.) The problem is that product engineering is unable or unwilling to give us their methodology unequivocally. It is unclear whether it is stupidity, laziness, or a turf battle that prevents them from letting us automate some of their daily tedium, but it provides us with endless opportunities to guess how they do their work and to respond to their fickle demands. They are hardly a group that has defined its problem well enough to engage outside contractors (local or global).

For example, we had a New England firm bid on a project for about 7-10 times an average engineer’s salary and wanted 15 months after receiving the complete spec. Well, another guy and I did it in-house in 9 months, and through weekly meetings with engineering, the spec constantly changed. The point is that our customer is so fickle, their efforts to engage outside contractors are doomed to failure, no matter where they are located.

Globalization where capital and goods can flow freely, but labor cannot is disasterous for all but the elite. Engaging in international trade must be done soberly and not under the rubric of deceptive slogans like “free trade.”

]]> By: Daniel Jalkut http://www.red-sweater.com/blog/316/coding-for-readability#comment-80595 Daniel Jalkut Sun, 08 Apr 2007 03:31:35 +0000 http://www.red-sweater.com/blog/316/coding-for-readability#comment-80595 macFanDave: I can appreciate your frustration, but I think the venom against developers from other countries is uncalled for. I hope you keep your job, but any further comments here along the lines of "Eff Them" will be deleted. We should look at globalization of the world as a positive, not as a negative. macFanDave: I can appreciate your frustration, but I think the venom against developers from other countries is uncalled for. I hope you keep your job, but any further comments here along the lines of “Eff Them” will be deleted.

We should look at globalization of the world as a positive, not as a negative.

]]> By: macFanDave http://www.red-sweater.com/blog/316/coding-for-readability#comment-80589 macFanDave Sun, 08 Apr 2007 03:12:25 +0000 http://www.red-sweater.com/blog/316/coding-for-readability#comment-80589 I've always thought the theory of readable, appropriately-commented code was compelling. Recently, my boss said that our company has signed agreements with Tata and Infosys to outsource our work to India. I'm glad that I have not really kept up with the theory of making my source readable. So, from now until the time I get fired or quit, I'm going to sharply increase my use of goto's, replace my scrupulously #define-d constants with mysterious "magic numbers" and start using Latin for variable and function names. F*cK them! I’ve always thought the theory of readable, appropriately-commented code was compelling.

Recently, my boss said that our company has signed agreements with Tata and Infosys to outsource our work to India. I’m glad that I have not really kept up with the theory of making my source readable.

So, from now until the time I get fired or quit, I’m going to sharply increase my use of goto’s, replace my scrupulously #define-d constants with mysterious “magic numbers” and start using Latin for variable and function names. F*cK them!

]]> By: Taybin http://www.red-sweater.com/blog/316/coding-for-readability#comment-80014 Taybin Sat, 07 Apr 2007 01:27:48 +0000 http://www.red-sweater.com/blog/316/coding-for-readability#comment-80014 I've seen suggestions to always use Enums instead of bools for better readability. Then you could do something like: <code>HANDLE myHandle = CreateEvent(myAttrs, ManualReset, NoInitialState, "Ouch");</code> I’ve seen suggestions to always use Enums instead of bools for better readability.

Then you could do something like:
HANDLE myHandle = CreateEvent(myAttrs, ManualReset, NoInitialState, "Ouch");

]]> By: Mike Jalkut http://www.red-sweater.com/blog/316/coding-for-readability#comment-79902 Mike Jalkut Fri, 06 Apr 2007 19:21:39 +0000 http://www.red-sweater.com/blog/316/coding-for-readability#comment-79902 Code may not be read very often, but when it is, it takes an inordinant amount of developer time to thoroughly (re)assess all the implications of changing it. Falling short in this scrutiny is what leads to unknown undesired sideeffects which take even more time to track down . . . usually after the product ships. Code may not be read very often, but when it is, it takes an inordinant amount of developer time to thoroughly (re)assess all the implications of changing it. Falling short in this scrutiny is what leads to unknown undesired sideeffects which take even more time to track down . . . usually after the product ships.

]]> By: Manton Reece http://www.red-sweater.com/blog/316/coding-for-readability#comment-79901 Manton Reece Fri, 06 Apr 2007 19:17:06 +0000 http://www.red-sweater.com/blog/316/coding-for-readability#comment-79901 Another simple way to make C functions like your example more readable is to pass constants instead of simply true or false. If done correctly these carry some of the meaning of what you would see in Objective-C plus the boolean value itself. But I agree with the general point of your post. It is generally not a good use of time to make sure every line of code is readable. Instead, refactor when you encounter a particularly messy part that you need to modify, and make sure that at least readable method names hide the most unreadable implementation guts. Another simple way to make C functions like your example more readable is to pass constants instead of simply true or false. If done correctly these carry some of the meaning of what you would see in Objective-C plus the boolean value itself.

But I agree with the general point of your post. It is generally not a good use of time to make sure every line of code is readable. Instead, refactor when you encounter a particularly messy part that you need to modify, and make sure that at least readable method names hide the most unreadable implementation guts.

]]> By: Andy Lee http://www.red-sweater.com/blog/316/coding-for-readability#comment-79891 Andy Lee Fri, 06 Apr 2007 19:02:54 +0000 http://www.red-sweater.com/blog/316/coding-for-readability#comment-79891 Amen to Cocoa gratitude. When I see a function name like EnableWindow(bool) whose job is not to enable a window, but to set the enabledness of a window, I get a bad feeling. Amen to Cocoa gratitude. When I see a function name like EnableWindow(bool) whose job is not to enable a window, but to set the enabledness of a window, I get a bad feeling.

]]> By: Karsten http://www.red-sweater.com/blog/316/coding-for-readability#comment-79889 Karsten Fri, 06 Apr 2007 18:57:23 +0000 http://www.red-sweater.com/blog/316/coding-for-readability#comment-79889 "I often overcome this problem by /* inline-commenting */ the parameters." well...this "c-part" of your cocoa-application may very well belong to the 90% of code you never touch again. and if you really happen to look at this code again you probably lookup the documentation for these functions again, or you may as well rewrite the code because you know better now and implement things in a simpler whay, that may even be easier to understand ;-) “I often overcome this problem by /* inline-commenting */ the parameters.”

well…this “c-part” of your cocoa-application may very well belong to the 90% of code you never touch again. and if you really happen to look at this code again you probably lookup the documentation for these functions again, or you may as well rewrite the code because you know better now and implement things in a simpler whay, that may even be easier to understand ;-)

]]>