I was wondering if anyone here wanted to take part in a Boost talk about real world programming experiences. Something like "rules to code by" or "nuggets of experience" or...? ie if you had to give your 1 favorite rule you code by, what would it be? For me it might be: - Inversion Principle or - Comments with the word "otherwise" are the best comments I could explain the Inversion Principle, or tell the story of when I started using "otherwise" in comments, within 10-15 minutes, maybe less. Then someone else could explain something helpful they've learned over the years. It could be the easiest way to get your feet wet in giving a talk - you just need to do a few minutes. I don't think there is much detail needed actually - I think just knowing that the author of so-and-so library actually does use TDD daily, or that a respected regular on the list does things this way, etc - just *knowing* that someone you respect does things a certain way, might be all that is needed. You can always find more details about certain rules/principles on the web, so in-depth explanations aren't really necessary. The important part, I think, is that someone you know (even just "virtually") is doing things that way. I'm thinking it would be called "How I Code". Not "How you should code" (although that might be implied). Just how each presenter codes in real world programming tasks. But I can't do this alone - no one wants to hear just about how I code - they want to hear about how you code. Plus I will probably have another Boost talk to frantically make last minute changes to, so I can't handle 2 talks - but I can help get people together and organize this and do a part. Overall, hopefully it would be more discussion than presentation, and maybe even some contradicting favorite rules - real life programming is never that simple such that one rule always works, right? Tony Van Eerd
On Wed, Feb 23, 2011 at 12:13 AM, Denis Shevchenko <for.dshevchenko@gmail.com> wrote:
23.02.2011 09:04, Gottlob Frege пишет:
if you had to give your 1 favorite rule you code by, what would it be?
Hm... 1 favorite rule? But what if I have a few equally favorite rules?
- Denis
Well, I already cheated and listed 2 for myself, but I think the challenge is to just pick one - showing how important that rule is. But if you are willing to be part of the talk, maybe once we get a few people involved, we could go over our rules and see if some rules are covered more than once, or there is a particular thing that you think everyone else is missing, and then that would be the item you would want to highlight. Or something like that. I'm open to suggestions. Tony
One of the most favorite rules of coding for me - *duplicate of code is evil*. I use various ways to get rid of the duplication: functions/functors, templates, inheritance, preprocessor and some "design features". - Denis
Since I likely won't be able to attend Boostcon yet again, my $0.02 favorite "How I code rule" is: You must copy, i.e. cut and paste, the code at least once, possibly twice, before making a function out of it through refactoring. This ensure that there are at least two use cases for the function and that the requirements for the function can be tested, that the function is justified, and that it actually makes sense. When I do not do this, I often create functions that I then add new parameters to, eventually those parameters turn into a structure, the structure becomes a class and the function becomes a method of the class....through aggressive refactoring, the code ends up the same, but it just takes longer. A related sub-rule of this is to name functions nounVerb() rather than verbNoun(). For example, circleDraw() rather than drawCircle(). This took me a while to get used to and it is purely for easier recognition of refactoring situations. For example, when circleDraw(), squareDraw(), ellipseDraw() show up, it starts becoming obvious that there is an opportunity for refactoring. This might only mean that draw() becomes a method of Circle or that there is a larger relationship between the nouns. Whatever it is, I find that placing the noun first helps me see this more quickly. I think this is a great idea for a talk and if it is made available on the video site afterwards, I'd be very interested in watching it. Brian
On Wed, Feb 23, 2011 at 1:36 PM, Brian Schrom <brian.schrom@pnl.gov> wrote:
Since I likely won't be able to attend Boostcon yet again, my $0.02 favorite "How I code rule" is:
You must copy, i.e. cut and paste, the code at least once, possibly twice, before making a function out of it through refactoring.
I like that your rule -somewhat- contradicts Denis' "duplication is evil". But if you are not there to talk about it, we will miss the subtleties, and Denis' side will "win". :-)
I think this is a great idea for a talk and if it is made available on the video site afterwards, I'd be very interested in watching it.
Brian
There should be videos (eventually) afterwards. See http://blip.tv/search?q=boostcon. But it is definitely not the same as being there. Tony
On Wed, Feb 23, 2011 at 1:04 AM, Denis Shevchenko <for.dshevchenko@gmail.com> wrote:
One of the most favorite rules of coding for me - *duplicate of code is evil*. I use various ways to get rid of the duplication: functions/functors, templates, inheritance, preprocessor and some "design features".
- Denis
Are you coming to BoostCon? Do you want to come on stage and show us the evils of code duplication? (We probably mostly all agree with you, but maybe you have some particular techniques you would like to share?) Tony
Hello Gottlob!
Are you coming to BoostCon? Unfortunately, no (it's not possible for me now). In addition, I don't speak English freely (although I'm learning). I'm from Russia... Do you want to come on stage and show us the evils of code duplication? I can show all my techniques there, or in some another place (maybe in some document). If you are interested, let me know.
Best regards, Denis
ie if you had to give your 1 favorite rule you code by, what would it be?
For me it's probably http://en.wikipedia.org/wiki/KISS_principle, or like I prefer to think about it "resist the temptation to overengineer things". Philippe
2011/2/23 Gottlob Frege <gottlobfrege@gmail.com>
ie if you had to give your 1 favorite rule you code by, what would it be?
One of my favorites: "Programs must be written for people to read, and only incidentally for machines to execute." -- Hal Abelson and Gerald Jay Sussman (Structure and Interpretation of Computer Programs) Regards Kris
Krzysztof Czainski wrote:
2011/2/23 Gottlob Frege <gottlobfrege@gmail.com>
ie if you had to give your 1 favorite rule you code by, what would it be?
One of my favorites: "Programs must be written for people to read, and only incidentally for machines to execute." -- Hal Abelson and Gerald Jay Sussman (Structure and Interpretation of Computer Programs)
I will add, libraries must be written for people to use, and only incidentally for people to read. Best, Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/Boost-Talk-How-I-Code-tp3320509p3322510.h... Sent from the Boost - Dev mailing list archive at Nabble.com.
On Thu, Feb 24, 2011 at 12:23 PM, Vicente Botet <vicente.botet@wanadoo.fr>wrote:
I will add, libraries must be written for people to use, and only incidentally for people to read.
Hmm.... I can see what you're getting at, but that could be just too much of a get out clause for impenetrable code - all you have to do is declare that this is 'library code', and suddenly you have license to write poorly. Surely all code should be written for people to read to the maximum practical extent. - Rob.
I will add, libraries must be written for people to use, and only incidentally for people to read. Disagree with you, Vicente. I think that libraries must be written for
people to use (this is certainly the most important thing) AND for people to read. IMHO, perfect library is clear for all: for users (interface) and for another developers (internal source code). - Denis
Denis Shevchenko wrote:
I will add, libraries must be written for people to use, and only incidentally for people to read.
Disagree with you, Vicente. I think that libraries must be written for people to use (this is certainly the most important thing) AND for people to read. IMHO, perfect library is clear for all: for users (interface) and for another developers (internal source code).
So there are some pretty clear tradeoffs between usability of library interfaces and readability of library code, particularly when it comes to generic programming. SFINAE makes function declarations pretty darn hard to read, but it makes error messages easier to read. Template meta-programming around generic interfaces makes library code hard to follow, but provides a service to the user that makes their code easier to write and read. It comes down to priorities and tradeoffs. Lack of readability of library code can be compensated for by excellent documentation. My priorities generally fall into this order: Schedule Portability Performance Usability Reduced Code Size Testability Readability Schedule is king. Other people may have a different order they prefer. Sometimes I increase usability at the expense of performance or reduce code size at the expense of performance. The order isn't absolute, but rather a qualitative notion of which priorities are given more weight in making tradeoffs during design. The way I code: think four times, code once. I think about my design goals (the priorities listed above) and how what I'm planning on coding relates to those design goals. I make design decisions conscious of what problem I'm trying to solve and what problems I'm creating. I think things all the way through up front before I start implementing. I implement very fast. I try to minimize the time I have to spend testing. Ideally, I want to spend 80% of my time thinking about how to solve problems and only 20% solving them by coding, testing and fixing bugs. I want to spend more time testing than fixing bugs and I want to spend more time coding than testing. I don't refactor code, I prefactor code. Once code is tested I only refactor it when there are bugs. When faced with problem code I prefer rewrite it to be clean rather than clean up dirty code. I only reuse code that is well tested, well designed and intended for reuse. I minimize external dependencies, even on we designed and well tested modules. The benefit of adding a dependency must greatly outweigh the cost. The most important metric for quality of code is that it works correctly. It is easy to take that for granted until you are faced with 50K lines of code bloat that is very readable and follows the OO-design-out-of-nowhere pattern but is riddled with bugs. The code you never need to read is the most "readable" code there is. Regards, Luke
Template meta-programming around generic interfaces makes library code hard to follow, but provides a service to the user that makes their code easier to write and read. Hm... Probably you are right. But, IMHO, template meta-code can be excellent, but may be awful, so it depends on developer... Lack of readability of library code can be compensated for by excellent documentation. Agree.
- Denis
Hi all, Sorry, I was away for a while there. Thanks for the interesting thread of discussion. It doesn't look like I/we will be doing a "How We Code and Why" talk at this BoostCon (for various reasons). But I would like to keep it in mind for next year. In particular, if anyone is interested (I'm looking at you Rob Riggs! but anyone else as well) maybe we could meet at this year's boostcon, and discuss plans for next year. I will be giving a talk on Lockfree Programming (again) this year (summarizing last year's talk and continuing where we left off), so after that talk (whenever it turns out to be) would be a great time to meet up with me, for example. Tony
On 1:59 PM, Vicente Botet wrote:
Krzysztof Czainski wrote:
One of my favorites: "Programs must be written for people to read, and only incidentally for machines to execute." -- Hal Abelson and Gerald Jay Sussman (Structure and Interpretation of Computer Programs)
I will add, libraries must be written for people to use, and only incidentally for people to read.
+1! Priority 1: make your caller's code clear. Priority 2: be clear yourself.
Jim Bell wrote:
On 1:59 PM, Vicente Botet wrote:
Krzysztof Czainski wrote:
One of my favorites: "Programs must be written for people to read, and only incidentally for machines to execute." -- Hal Abelson and Gerald Jay Sussman (Structure and Interpretation of Computer Programs)
I will add, libraries must be written for people to use, and only incidentally for people to read.
+1!
Priority 1: make your caller's code clear. Priority 2: be clear yourself.
+1 http://www.developerdotstar.com/mag/articles/reeves_design_main.html
participants (10)
-
Brian Schrom -
Denis Shevchenko -
Gottlob Frege -
Jeff Flinn -
Jim Bell -
Krzysztof Czainski -
Philippe Vaucher -
Robert Jones -
Simonson, Lucanus J -
Vicente Botet