Re: Uncle Bob on Coding Standards
H.Merijn Brand wrote: Just only today I hit an M$Access database with a table named `./onderw`.`Bus; Taxi; Auto` My mail client inexplicably just quit. I assume because it was so disgusted. -- David Cantrell
Re: Uncle Bob on Coding Standards
On Tue, 14 Dec 2004 23:10:51 +0100, H.Merijn Brand [EMAIL PROTECTED] wrote: Yes. Ditch emacs. It knows only the *wrong* styles. Way to totally make a cogent argument. Next I suppose we'll hear about how the Sun compilers totally pwn gcc2. -- Shawn Boyette [EMAIL PROTECTED]
Re: Uncle Bob on Coding Standards
On Dec 14, 2004, at 2:10 PM, H.Merijn Brand wrote: On Tue 14 Dec 2004 21:49, Michael G Schwern [EMAIL PROTECTED] wrote: Here's what I have to say about clever bracing/spacing styles. Your bracing/spacing style should not be a detriment. It should not be a limitation. If common editors have trouble dealing with it, you've just limited your tool set. Yes. Ditch emacs. It knows only the *wrong* styles. uh... yeah... okay. You realize elisp is Turing-complete, right? So, unless your style is logically inconsistent, emacs can do it. -kevin
Re: Uncle Bob on Coding Standards
On Tue, 14 Dec 2004 14:21:40 -0800, Kevin Scaldeferri [EMAIL PROTECTED] wrote: On Dec 14, 2004, at 2:10 PM, H.Merijn Brand wrote: Yes. Ditch emacs. It knows only the *wrong* styles. uh... yeah... okay. You realize elisp is Turing-complete, right? Um, yeah. Right. My cat is Turing complete. What's your point again? So, unless your style is logically inconsistent, emacs can do it. And even if your style is logically inconsistent, illogical, immoral, or unethical, emacs can do it. :wq
Re: Uncle Bob on Coding Standards
On Tue 14 Dec 2004 15:15, [EMAIL PROTECTED] (Dominic Mitchell) wrote: On Tue, Dec 14, 2004 at 12:21:50PM +, Matt Sergeant wrote: On 14 Dec 2004, at 11:26, Clayton, Nik wrote: To be honest, I don't care if someone's house style is for TAB to indent 2, 4, or 8 characters; how much second level indentations are indented by; whether or not braces cuddle 'else'; and so on. That's something the editor can care about. When I hit the TAB key it should just do whatever the house style requires. But what about when I'm using notepad.exe??? Or an even more common example, my laser printer? Tabs are 8 spaces. Printers know this. Terminals know this. Even browsers know this. Do the world a favour and don't tell your editor otherwise. I /think/ he means what the tab key's effect is when typed in his editor of choice most vi clones have some knowledge about using the tab key on the start of a line, translating it to shiftwidth, which can be any number. That the editor replaces every amount of spaces (default 8) with a tab should not be the coders problem. Some editors also have the option to not use tabs at all and expand all leading whitespace to spaces. I /think/ that is what Nik meant. But we're adrift here. This was not the subject of the original post. [ If you're using notepad, you're not a real coder. vim/elvis is also available on winblows ] Kane has a sig that sais: real coders use cat a.out -- H.Merijn BrandAmsterdam Perl Mongers (http://amsterdam.pm.org/) using perl-5.6.1, 5.8.5, 5.9.x, and 809 on HP-UX 10.20 11.00, 11i, AIX 4.3, AIX 5.2, SuSE 9.1, and Win2k. http://www.cmve.net/~merijn/ http:[EMAIL PROTECTED]/ [EMAIL PROTECTED] send smoke reports to: [EMAIL PROTECTED], QA: http://qa.perl.org
Re: Uncle Bob on Coding Standards
On Tue 14 Dec 2004 18:21, Ricardo SIGNES [EMAIL PROTECTED] wrote: * H.Merijn Brand [EMAIL PROTECTED] [2004-12-14T11:28:19] About spaces, another thing springs to mind, for which I would gladly kill the responsible people to allow it (I bet M$ was the first to push it): Spaces in database table and field names. DON'T! NEVER! Once you start it, you will never be able to escape the quicksands of (incompatible) quotation and unportability of your scripts, be that in sql, sh, perl/dbi, hli, or e/sql SELECT rsUniqueId FROM [SQL-ABCdatabase2K]..tblsTABLE as t JOIN [SQL-ABCdatabase2K]..tblwPRODUCT p ON p.ABC P/N = t.rsProductCode WHERE p.id IN (SELECT ItemIdentifier FROM tblSomeIds) Just only today I hit an M$Access database with a table named `./onderw`.`Bus; Taxi; Auto` Ahhrg! /me runs for cover! -- H.Merijn BrandAmsterdam Perl Mongers (http://amsterdam.pm.org/) using perl-5.6.1, 5.8.5, 5.9.x, and 809 on HP-UX 10.20 11.00, 11i, AIX 4.3, AIX 5.2, SuSE 9.1, and Win2k. http://www.cmve.net/~merijn/ http:[EMAIL PROTECTED]/ [EMAIL PROTECTED] send smoke reports to: [EMAIL PROTECTED], QA: http://qa.perl.org
Re: Uncle Bob on Coding Standards
Here's all I have to say about tabs. I expect the source to look the same no matter whose editor, pager, printer or utility I run it through. Literal tabs violate this. The end. Here's what I have to say about clever bracing/spacing styles. Your bracing/spacing style should not be a detriment. It should not be a limitation. If common editors have trouble dealing with it, you've just limited your tool set. If programmers outside your project look at it and go Huh? you've just lost yourself a potential patch as they recoil. If its so different that looking at other common bracing styles is now odious to you, that's a communication problem. Part of easy communication is taking advantage of common idioms and conventions. Doesn't matter how clever it is, if its causing conflict with outsiders, dump it. -- Michael G Schwern[EMAIL PROTECTED] http://www.pobox.com/~schwern/ Schwern Unit: a positive but insignificant quantity
Re: Uncle Bob on Coding Standards
On Tue 14 Dec 2004 21:49, Michael G Schwern [EMAIL PROTECTED] wrote:
Here's all I have to say about tabs.
I expect the source to look the same no matter whose editor, pager, printer
or utility I run it through. Literal tabs violate this. The end.
Here's what I have to say about clever bracing/spacing styles.
Your bracing/spacing style should not be a detriment. It should not
be a limitation. If common editors have trouble dealing with it,
you've just limited your tool set.
Yes. Ditch emacs. It knows only the *wrong* styles.
If programmers outside your project look at it and go Huh? you've just
lost yourself a potential patch as they recoil.
Don't think so. spaces and bracing is hard to do it so bad as to other people
unable to be able to read it. It is merely easy to the eye if there is logic,
and maybe more important consistency in indents
if(expr)
{ func( args ) }else{
statement; }
func ( args);
if (expr)
statement;
wrong_indent;
and yet more misleading indent;
if (expr) {
foo (1);
}
That is *bad*
If its so different that looking at other common
bracing styles is now odious to you, that's a communication problem.
Part of easy communication is taking advantage of common idioms and
conventions. Doesn't matter how clever it is, if its causing conflict with
outsiders, dump it.
No way. Ever.
If I feel compelled enough to deal with other peoples code, I will adapt where
needed. The fact that I'm a perl5 commiter is a vivid proof of that. If I had
imposed my style on all patches I submitted or applied, I would have been
kicked a long time ago.
We have a small company, and if you like to work with us, you adapt to our
style. Not vise versa. Period.
I've also learned that over time, you can get used to (almost) any style,
given there is some logic about it. I've had to change a lot of my habits in
all the compromises we made, but got used to it.
--
H.Merijn BrandAmsterdam Perl Mongers (http://amsterdam.pm.org/)
using perl-5.6.1, 5.8.5, 5.9.x, and 809 on HP-UX 10.20 11.00, 11i,
AIX 4.3, AIX 5.2, SuSE 9.1, and Win2k. http://www.cmve.net/~merijn/
http:[EMAIL PROTECTED]/ [EMAIL PROTECTED]
send smoke reports to: [EMAIL PROTECTED], QA: http://qa.perl.org
Re: Uncle Bob on Coding Standards
On Tue, Dec 14, 2004 at 11:10:51PM +0100, H.Merijn Brand wrote: If programmers outside your project look at it and go Huh? you've just lost yourself a potential patch as they recoil. Don't think so. spaces and bracing is hard to do it so bad as to other people unable to be able to read it. It is merely easy to the eye if there is logic, and maybe more important consistency in indents Keeping it within the set of sane bracing styles, ones that perform the basic functions of indentation and blocking and are not obviously broken (and yes, I'm including yours in this set :), and not drifting off into straw-men... Style is a matter of allowing rapid communcation without having to puzzle out the internal logic. Done right, good style allows one to skim code without having to study it. Any style can be learned, but want to have to do as little learning as possible to read somebody's code. Most everyone expects the closing brace to be at the indentation level on which the conditional started. Not at the level at which the code inside the block is written. There's really no quantifiable advantage to either way, its a matter of expectations. In such cases go with the one that violates the least number of potential worker's expectations and eliminates Yet Another thing they have to learn to work on your code. To put it in different terms I turn to industrial design. Donald Norman in Turn Signals Are The Facial Expressions Of Automobiles has a chapter entitled How Long Is Noon? in which he talks about our time formatting. In it he talks about AM, PM and now 12 noon and 12 midnight should be distinguished. One argument is this: AM is an abbreviation of Ante Meridiem, latin for before the middle of the day. PM is Post Meridiem, after midday. As they are abbreviations they are correctly written A.M. and P.M.. Noon is the meridiem therefore noon should be labeled 12 M. This is perfectly sensible logic... if you know latin, speak a romance language or know the history of modern terms. For your average English speaker who does not have any of this background it makes no sense whatsoever. Perfectly logic systems can make absolutely no sense if the reader does not have your frame of reference. Often the case. As programmers we love logically consistent systems and think that because something is logical it is usable. This ignores the frame of reference for the reader. If they do not have your background and know your logic your perfectly sensible system can become inscritable. This is why AM is AM, PM is PM, and 12 M is 12 midmnight. To most people AM and PM are just archaic symbols for before noon and after noon and it doesn't matter one wit that they happen to be abbreviations of latin phrases. We may lament the historical loss but that doesn't matter. What matters is clarity of communications. When there's no obvious improvement between one format or the other, go with the one that follows understoood conventions. That last bit is important. When there *is* a noticable improvement then consider going with it. In this example it would be 24 hour time. [1] Which I'm sure will now spark a nice, pointless debate between the Europeans and Americans. Donald Norman lays out the arguments for 24 hour time nicely. The book can be had for $4 used. -- Michael G Schwern[EMAIL PROTECTED] http://www.pobox.com/~schwern/ AY! The ground beef, she is burning my groin! http://sluggy.com/d/990105.html
Re: Uncle Bob on Coding Standards
On Tue 14 Dec 2004 17:10, Adam Turoff [EMAIL PROTECTED] wrote: On Tue, 14 Dec 2004 16:14:32 +0100, H.Merijn Brand [EMAIL PROTECTED] wrote: On Tue 14 Dec 2004 16:04, Clayton, Nik [EMAIL PROTECTED] wrote: I've normally got enough going on in my head when writing code, worrying about the house style should not be one of them. Wrong. It should be. You write, and someone else - or yourself - has to maintain the code later. This means that you have to write with style and maintainability in focus. All the time. Part of the problem is that coding style mixes a bunch of unrelated issues of varying importance. I'm with Nik that I don't care overmuch about how many spaces go around parens, whether curlys are cuddled or uncuddled, or tab expansion idiosyncracies. But there *are* issues of coding style that are of tremendous import, and can add or reduce friction on a project, especially as it grows. Things like line length, method length, naming conventions, file layout, idiomatic usage[*], etc. One example I've used in the past is from a project I worked on (in C) where we were dealing with real estate data numbers, commonly abbreviated 'rednum'. Except that they were also named, 'red', 'redno', 'rnum', 'red_num', 'red_no', 'r_num', and so on. In both variables and Ohhh, the horror. And so recognizable! functions. This was one of many sources of dissonance (and compiler errors) on the project, and was a continual drag on team productivity. Instead of just *knowing* what you needed, you often needed to grovel through half a dozen source files to figure out what you *should* have typed. This was underlighted in my example, but indeed evenly important. We've chosen to make default prefixes to veriables to reflect the (database) type: d_end All dates start with d_ (we use plain numeric 8 MMDD because none of the databases we work with have compatible date formats (fwiw we also have d_end_y, d_end_m, and d_end_d, which I now presume does not need any further explanation :)) c_city (key) code of a field that has a reference table s_city The string value for c_city and so on. But we all used the same brace placement and indenting styles. ;-) About spaces, another thing springs to mind, for which I would gladly kill the responsible people to allow it (I bet M$ was the first to push it): Spaces in database table and field names. DON'T! NEVER! Once you start it, you will never be able to escape the quicksands of (incompatible) quotation and unportability of your scripts, be that in sql, sh, perl/dbi, hli, or e/sql If you want to have portability in mind, adhere to the lowest level of available standards and don't be tempted to use archaic functions specific to a unique version of a database on a unique version of an operating system wich only runs on a specific architecture. FWIW the style I use was decided upon back in the 80's when we (me and 6 others) had to do a huge software project at school and we did discuss style before we started. The biggest argue was about the length of the variable names to use. This is where I think Uncle Bob is right -- the standards need to evolve. On this same project, there was a coding standard in place at the onset, but it standardized trivialities. Because we had a coding standard, we never saw the bigger issues of naming conventions as problems a coding standard could/should fix, so everyone improvised in their own special way with the stuff that wasn't standardized. At the onset, though, a lot of issues we had to deal with were completely unknown, since the project took three or four major course changes over the years. If all of this is true, I think we made marvellous decisions in our school days, because none of my coding standards have changed, but the decrease of an indent of 6 (very nice when programming PASCAL) to an indent of 4 (better suited for almost any other language, and since TAB is 8, much more efficient). Z. *: For example: design with closures and coderefs in mind, or with big modules with 17 optional features or 15 variations on the same method; are you intetionally using or avoiding map and grep?; what are the standard modules your project uses to write new classes? -- H.Merijn BrandAmsterdam Perl Mongers (http://amsterdam.pm.org/) using perl-5.6.1, 5.8.5, 5.9.x, and 809 on HP-UX 10.20 11.00, 11i, AIX 4.3, AIX 5.2, SuSE 9.1, and Win2k. http://www.cmve.net/~merijn/ http:[EMAIL PROTECTED]/ [EMAIL PROTECTED] send smoke reports to: [EMAIL PROTECTED], QA: http://qa.perl.org
Re: Uncle Bob on Coding Standards
* H.Merijn Brand [EMAIL PROTECTED] [2004-12-14T11:28:19] About spaces, another thing springs to mind, for which I would gladly kill the responsible people to allow it (I bet M$ was the first to push it): Spaces in database table and field names. DON'T! NEVER! Once you start it, you will never be able to escape the quicksands of (incompatible) quotation and unportability of your scripts, be that in sql, sh, perl/dbi, hli, or e/sql SELECT rsUniqueId FROM [SQL-ABCdatabase2K]..tblsTABLE as t JOIN [SQL-ABCdatabase2K]..tblwPRODUCT p ON p.ABC P/N = t.rsProductCode WHERE p.id IN (SELECT ItemIdentifier FROM tblSomeIds) Yup. -- rjbs pgpTjX4YpMvlh.pgp Description: PGP signature
Re: Uncle Bob on Coding Standards
On Tue, Dec 14, 2004 at 11:15:13AM +, Ben Evans wrote: On Tue, Dec 14, 2004 at 05:35:53AM -0500, Michael G Schwern wrote: Tripped across this on WardsWiki just now. #5 is my favorite as its often forgotten in the noise. Oh, the noise! Oh, the noise! Noise! Noise! Noise! That's one thing he hated! The NOISE! NOISE! NOISE! NOISE! To repeat #5, coding style is about communication. The goal of style is not to enforce consistency. It is to make the code easier to read. They allow one programmer to talk to the other through the code without a lot of unnecessary in-the-head translation going on. Style should not get bogged down in syntactical issues, and we Perl programmers love our syntax. Thank you all for the demonstration. The tricker problems are the higher order problems. How are variables and methods named? When do we split something off into a method? Into its own file? When do we use OO when do we use functions? What's the preferred date handling module? What are the error handling conventions? What are the *abstractions*? -- Michael G Schwern[EMAIL PROTECTED] http://www.pobox.com/~schwern/ OH GOD!! It's LINUX! All you Linux fanboys go wild! It never crashes! It'll wash your underpants! It'll eat your dog for you, if you want your dog to be eaten! It'll make you attractive and smell good and... it'll... uh... uh. Man, I'm so sick of this shit. http://www.goats.com/archive/000602.html
Uncle Bob on Coding Standards
Tripped across this on WardsWiki just now. #5 is my favorite as its often forgotten in the noise. http://www.c2.com/cgi/wiki?UncleBobOnCodingStandards On coding standards: 1. Let them evolve during the first few iterations. 2. Let them be team specific instead of company specific. 3. Don't write them down if you can avoid it. Rather, let the code be the way the standards are captured. 4. Don't legislate good design. (e.g. don't tell people not to use goto) 5. Make sure everyone knows that the standard is about communication, and nothing else. 6. After the first few iterations, get the team together to decide. -- Michael G Schwern[EMAIL PROTECTED] http://www.pobox.com/~schwern/ Abandon failing tactics.
Re: Uncle Bob on Coding Standards
On Tue, Dec 14, 2004 at 05:35:53AM -0500, Michael G Schwern wrote: Tripped across this on WardsWiki just now. #5 is my favorite as its often forgotten in the noise. http://www.c2.com/cgi/wiki?UncleBobOnCodingStandards On coding standards: 1. Let them evolve during the first few iterations. 2. Let them be team specific instead of company specific. 3. Don't write them down if you can avoid it. Rather, let the code be the way the standards are captured. 4. Don't legislate good design. (e.g. don't tell people not to use goto) 5. Make sure everyone knows that the standard is about communication, and nothing else. 6. After the first few iterations, get the team together to decide. For small to medium sized systems, built by a small team of very bright people, this might work. For large systems, particularly ones which evolve and grow over time, which have large numbers of interacting subsystems and/or which have a mixture of bright and not-so bright people this is very bad advice. 1. Let them evolve during the first few iterations. Given that the code will be imperfectly and incompletely refactored, Rule 1 ensures that code which is not in accord with standard will persist in the codebase 2. Let them be team specific instead of company specific. In systems with a large number of interacting subsystems, this makes obtaining an architectural overview much harder, as developers must constantly switch between styles. Worse still, this raises the possibility of subtle bugs due to the same syntactic convention having different semantics in code written by different teams. Might I offer: 2a. Allow each team to choose their own cutesy name for each pattern they use, which best embodies how the team feels about that particular pattern. ... 3. Don't write them down if you can avoid it. Rather, let the code be the way the standards are captured. This ensures that new starters are at best unproductive and at worst positively harmful. New people have enough to do to get up to speed. A treasure hunt for the coding standards shouldn't be one of them. 4. Don't legislate good design. (e.g. don't tell people not to use goto) Not everyone who touches every codebase can be trusted to know what good design is. This should, of course, be caught at the hiring stage, but not every organisation is so fortunate. 5. Make sure everyone knows that the standard is about communication, and nothing else. But not every standard has the same expressive power. One aspect of this is reducing the documentation load on the developer. As documentation will be the first part of any project to go over the side, rule 5 and rule 2 and rule 3 are inconsistent. 6. After the first few iterations, get the team together to decide. Inviting junior programmers and their frequently One True Way outlook to those type of design discussions is unlikely to be productive. I'm a little ray of sunshine today. It's not that I think Agile methods don't work, but for a methodology that has so much to say about project Scope, I think some discussion of the scope of applicability of the methods might be worthwhile. Ben
RE: Uncle Bob on Coding Standards
http://www.c2.com/cgi/wiki?UncleBobOnCodingStandards On coding standards: I'd add an additional: * Make sure your tools enforce them, and make complying with them as simple as possible. To be honest, I don't care if someone's house style is for TAB to indent 2, 4, or 8 characters; how much second level indentations are indented by; whether or not braces cuddle 'else'; and so on. That's something the editor can care about. When I hit the TAB key it should just do whatever the house style requires. N
Re: Uncle Bob on Coding Standards
On Tue 14 Dec 2004 12:15, Ben Evans [EMAIL PROTECTED] wrote: On Tue, Dec 14, 2004 at 05:35:53AM -0500, Michael G Schwern wrote: Tripped across this on WardsWiki just now. #5 is my favorite as its often forgotten in the noise. http://www.c2.com/cgi/wiki?UncleBobOnCodingStandards On coding standards: 1. Let them evolve during the first few iterations. 2. Let them be team specific instead of company specific. 3. Don't write them down if you can avoid it. Rather, let the code be the way the standards are captured. 4. Don't legislate good design. (e.g. don't tell people not to use goto) 5. Make sure everyone knows that the standard is about communication, and nothing else. 6. After the first few iterations, get the team together to decide. For small to medium sized systems, built by a small team of very bright people, this might work. For large systems, particularly ones which evolve and grow over time, which have large numbers of interacting subsystems and/or which have a mixture of bright and not-so bright people this is very bad advice. 1. Let them evolve during the first few iterations. Given that the code will be imperfectly and incompletely refactored, Rule 1 ensures that code which is not in accord with standard will persist in the codebase 2. Let them be team specific instead of company specific. In systems with a large number of interacting subsystems, this makes obtaining an architectural overview much harder, as developers must constantly switch between styles. Worse still, this raises the possibility of subtle bugs due to the same syntactic convention having different semantics in code written by different teams. Might I offer: 2a. Allow each team to choose their own cutesy name for each pattern they use, which best embodies how the team feels about that particular pattern. ... 3. Don't write them down if you can avoid it. Rather, let the code be the way the standards are captured. This ensures that new starters are at best unproductive and at worst positively harmful. New people have enough to do to get up to speed. A treasure hunt for the coding standards shouldn't be one of them. 4. Don't legislate good design. (e.g. don't tell people not to use goto) Not everyone who touches every codebase can be trusted to know what good design is. This should, of course, be caught at the hiring stage, but not every organisation is so fortunate. 5. Make sure everyone knows that the standard is about communication, and nothing else. But not every standard has the same expressive power. One aspect of this is reducing the documentation load on the developer. As documentation will be the first part of any project to go over the side, rule 5 and rule 2 and rule 3 are inconsistent. 6. After the first few iterations, get the team together to decide. Inviting junior programmers and their frequently One True Way outlook to those type of design discussions is unlikely to be productive. Not entirely true. These discussions give the more experienced programmers a chance to explain *why* the applied coding standards were chosen in the first place. Once they (try to) understand that, adapting to it might be much easier for them. As an example here, we have 5 coders, and all like to use a different style (in fact one of them does not care at all about style, which is even worse). We had a *huge* discussion about the style we wanted here for corporate stuff, and we made compromises to make as many people as happy as possible. That works. We can all read, understand, and - most important - maintain each others code now, which includes C, perl, sh, and 4GL code. Also important is to choose styles that match the people that *stay* with the company. Here, the avarage coder already works for over 10 years with this firm, and if we would let our styles be guided by someone we would hire for a few month to help us through busy times, that would be very counterproductive. My stance is to enforce clean and styled code from the very beginning, because chances are high that working code won't be changed afterwords just to meet the coding standards (exceptions I just met was C code for which the most recent change was back in 1998 and was - for available compiler reasons on that platform - not yet in strict ANSI with prototypes etc. I had to rewrite all function headers to meet the newer strictnesses, and modified some cruft to meet the current standards, making the code free of all warnings for gcc -Wall and HP's C-ANSI-C, which is also very strict). Perl scripts written for production cannot be shipped without use strict and use warnings. Period. In case of disagreement, I decide :) I'm a little ray of sunshine today. It's not that I think Agile methods don't work, but for a methodology that has so much to say about project Scope, I think some
Re: Uncle Bob on Coding Standards
On Tue, Dec 14, 2004 at 12:21:50PM +, Matt Sergeant wrote: On 14 Dec 2004, at 11:26, Clayton, Nik wrote: To be honest, I don't care if someone's house style is for TAB to indent 2, 4, or 8 characters; how much second level indentations are indented by; whether or not braces cuddle 'else'; and so on. That's something the editor can care about. When I hit the TAB key it should just do whatever the house style requires. But what about when I'm using notepad.exe??? Or an even more common example, my laser printer? Tabs are 8 spaces. Printers know this. Terminals know this. Even browsers know this. Do the world a favour and don't tell your editor otherwise. -Dom
Re: Uncle Bob on Coding Standards
On 14 Dec 2004, at 11:26, Clayton, Nik wrote: http://www.c2.com/cgi/wiki?UncleBobOnCodingStandards On coding standards: I'd add an additional: * Make sure your tools enforce them, and make complying with them as simple as possible. To be honest, I don't care if someone's house style is for TAB to indent 2, 4, or 8 characters; how much second level indentations are indented by; whether or not braces cuddle 'else'; and so on. That's something the editor can care about. When I hit the TAB key it should just do whatever the house style requires. But what about when I'm using notepad.exe??? __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: Uncle Bob on Coding Standards
I /think/ he means what the tab key's effect is when typed in his editor of choice Correct. Hitting TAB should indent to the correct level for the current context. I don't especially care whether the editor does by inserting actual TAB characters or a bunch of spaces. I've normally got enough going on in my head when writing code, worrying about the house style should not be one of them. N PS: This is probably my pet peeve about writing FreeBSD code. There's no Emacs style(9) mode (although you can come close), and last time I checked, some of style(9) really can't be implemented automatically. To my mind, that's a bug in the house style...
Re: Uncle Bob on Coding Standards
On Tue 14 Dec 2004 16:04, Clayton, Nik [EMAIL PROTECTED] wrote: I /think/ he means what the tab key's effect is when typed in his editor of choice Correct. Hitting TAB should indent to the correct level for the current context. I don't especially care whether the editor does by inserting actual TAB characters or a bunch of spaces. I've normally got enough going on in my head when writing code, worrying about the house style should not be one of them. Wrong. It should be. You write, and someone else - or yourself - has to maintain the code later. This means that you have to write with style and maintainability in focus. All the time. PS: This is probably my pet peeve about writing FreeBSD code. There's no Emacs style(9) mode (although you can come close), and last time I checked, some of style(9) really can't be implemented automatically. To my mind, that's a bug in the house style... I hate emacs because it cannot support my indent style (and also because it is a system resource hog). I've had several people trying to set emacs' preferences to what we use here, but emacs just does not want to do it. It's completely focused on the (IMHO wrong) style used with the GNU software projects, which is one of the reasons I've always turned down requests to help maintain any of their projects. FWIW the style I use was decided upon back in the 80's when we (me and 6 others) had to do a huge software project at school and we did discuss style before we started. The biggest argue was about the length of the variable names to use. -- H.Merijn BrandAmsterdam Perl Mongers (http://amsterdam.pm.org/) using perl-5.6.1, 5.8.5, 5.9.x, and 809 on HP-UX 10.20 11.00, 11i, AIX 4.3, AIX 5.2, SuSE 9.1, and Win2k. http://www.cmve.net/~merijn/ http:[EMAIL PROTECTED]/ [EMAIL PROTECTED] send smoke reports to: [EMAIL PROTECTED], QA: http://qa.perl.org
RE: Uncle Bob on Coding Standards
I've normally got enough going on in my head when writing code, worrying
about the house style should not be one of them.
Wrong. It should be. You write, and someone else - or yourself - has to
maintain the code later. This means that you have to write with style and
maintainability in focus. All the time.
style yes. house style no. I don't especially care whether a group
prefers 4 character indents, 8 character indents,
if(foo) {
}
or
if(foo)
{
}
That's what the tools are for. Those are all religious issues that I'm
not interested in.
Not having to worry about those because the tools deal with them means
I can worry about how best to express what I'm trying to achieve in the
code (a) to whoever maintains it after me, and (b) to the machine that's
going to be executing it.
N
Re: Uncle Bob on Coding Standards
On Tue, Dec 14, 2004 at 02:15:45PM +, Dominic Mitchell wrote: On Tue, Dec 14, 2004 at 12:21:50PM +, Matt Sergeant wrote: On 14 Dec 2004, at 11:26, Clayton, Nik wrote: That's something the editor can care about. When I hit the TAB key it should just do whatever the house style requires. But what about when I'm using notepad.exe??? Or an even more common example, my laser printer? Tabs are 8 spaces. Printers know this. Terminals know this. Even browsers know this. Do the world a favour and don't tell your editor otherwise. He didn't say he was insterting tab characters, he said he was pressing his tab key. Not the same thing. The combination of tabs and spaces inserted when I press tab depends on the type of file I'm editing. andrew -- Capricorn: (Dec. 22 - Jan. 19) It's beginning to look like you'll never understand that ruffled skirts don't look good with coloured stockings, especially on men with legs like yours.
Re: Uncle Bob on Coding Standards
On Tue 14 Dec 2004 16:21, Clayton, Nik [EMAIL PROTECTED] wrote:
I've normally got enough going on in my head when writing code, worrying
about the house style should not be one of them.
Wrong. It should be. You write, and someone else - or yourself - has to
maintain the code later. This means that you have to write with style and
maintainability in focus. All the time.
style yes. house style no. I don't especially care whether a group
prefers 4 character indents, 8 character indents,
if(foo) {
}
or
if(foo)
{
}
if (expr) {
statement;
function (argument, ...);
}
That's what the tools are for. Those are all religious issues that I'm
not interested in.
Tools can seriously fuck up code, especially when embedded (database) code is
involved. We don't use formatting tools just because of that. (re)formatters
might work on machine/architecture A, but totally kill a specific
(pre)processor somewhere else.
Not having to worry about those because the tools deal with them means
I can worry about how best to express what I'm trying to achieve in the
code (a) to whoever maintains it after me, and (b) to the machine that's
going to be executing it.
Not worrying about those issues have taken far too much of my time in the past
because
1. Other preprocessors could not cope with it. Don't blame the manufacturer,
because it will take exponential amounts of time to convince IBM or
Micro$hit to admit it's their fault (yes, for me it was a faulty IBM cpp)
2. It will take someone later on an incredible amount of (lost) time to fix
the non-house-style to house style, because it /will/ be decided somewhere
in the future that everything has to be in house style, and that will
probably not be *you* who decides so. If /I/ was the one to decide, and
/you/ were the one to refuse, you are out. So it's also a good way to keep
friends with your co-workers and lessen the chance to be fired first.
--
H.Merijn BrandAmsterdam Perl Mongers (http://amsterdam.pm.org/)
using perl-5.6.1, 5.8.5, 5.9.x, and 809 on HP-UX 10.20 11.00, 11i,
AIX 4.3, AIX 5.2, SuSE 9.1, and Win2k. http://www.cmve.net/~merijn/
http:[EMAIL PROTECTED]/ [EMAIL PROTECTED]
send smoke reports to: [EMAIL PROTECTED], QA: http://qa.perl.org
Re: Uncle Bob on Coding Standards
On Tue, 14 Dec 2004 16:14:32 +0100, H.Merijn Brand [EMAIL PROTECTED] wrote: On Tue 14 Dec 2004 16:04, Clayton, Nik [EMAIL PROTECTED] wrote: I've normally got enough going on in my head when writing code, worrying about the house style should not be one of them. Wrong. It should be. You write, and someone else - or yourself - has to maintain the code later. This means that you have to write with style and maintainability in focus. All the time. Part of the problem is that coding style mixes a bunch of unrelated issues of varying importance. I'm with Nik that I don't care overmuch about how many spaces go around parens, whether curlys are cuddled or uncuddled, or tab expansion idiosyncracies. But there *are* issues of coding style that are of tremendous import, and can add or reduce friction on a project, especially as it grows. Things like line length, method length, naming conventions, file layout, idiomatic usage[*], etc. One example I've used in the past is from a project I worked on (in C) where we were dealing with real estate data numbers, commonly abbreviated 'rednum'. Except that they were also named, 'red', 'redno', 'rnum', 'red_num', 'red_no', 'r_num', and so on. In both variables and functions. This was one of many sources of dissonance (and compiler errors) on the project, and was a continual drag on team productivity. Instead of just *knowing* what you needed, you often needed to grovel through half a dozen source files to figure out what you *should* have typed. But we all used the same brace placement and indenting styles. ;-) FWIW the style I use was decided upon back in the 80's when we (me and 6 others) had to do a huge software project at school and we did discuss style before we started. The biggest argue was about the length of the variable names to use. This is where I think Uncle Bob is right -- the standards need to evolve. On this same project, there was a coding standard in place at the onset, but it standardized trivialities. Because we had a coding standard, we never saw the bigger issues of naming conventions as problems a coding standard could/should fix, so everyone improvised in their own special way with the stuff that wasn't standardized. At the onset, though, a lot of issues we had to deal with were completely unknown, since the project took three or four major course changes over the years. Z. *: For example: design with closures and coderefs in mind, or with big modules with 17 optional features or 15 variations on the same method; are you intetionally using or avoiding map and grep?; what are the standard modules your project uses to write new classes?
