code aesthetics
-
Thanks very much for taking the time on this post, it's given me a lot of food for thought! We have a wiki in our department, but this is not being used for standards(at least as far as I know!), so this may be a good place to start. I'll take on board what you've said and think about what the next step is. You mentioned a cultural shift, there are several things here that need to be shifted culturally here (IMO) and the above is just one of those.. there are loads of other things also need to be looked at, but I won't moan about those! Cheers,
Billy. MCPD Windows Developer "Duct tape is like the force, it has a light side, a dark side and it holds the universe together!" - Anonymous my holding page..more coming soon!
Hi Billy, No problem at all. This is an interesting and sometimes frustrating topic. It requires large amounts of energy and you need management buy in. Sometimes training courses can inspire change. Alternatively start your own company with your own culture! One of the reasons Toyota is so successful is because they pay so much attention to their company culture. Plus processes and standards are not used appropriately in many organisations, where they become stuffy, and inflexible and even seems to inhibit work. On the other hand if used appropriately they can act as steps on the stairway to perfection. You end up getting so ahead of your competitors that their is oceans between you. As is the case with Toyota. If you find this all interesting i would recommend reading the E-Myth by Micheal Gerber (or the audio book) and/or the Toyota way, this is especially useful if you are considering starting your own business.
Steve O'Brien A successful person isn't necessarily better than her less successful peers at solving problems; her pattern-recognition facilities have just learned what problems are worth solving. - Ray Kurzweil www.newicon.net
-
Do any of your developers ever find there to be a need to print sections of code? That is still a pretty good lowest common denominator (80 cols for readability on an 8.5 x 11 page) which makes me hesitate to accept anything greater than 80 columns width in the code.
I'm a firm believer in the 80 column limit myself (I, too, am a code nazi). But pick a different font and you can easily print 120 columns on even the crappiest of printers. Consolas is your friend.
-
geoffs wrote:
knowing that just because I think a particular guideline is good doesn't necessarily mean it really is
That's an excellent start. It's important that your standards are a result of quality input from the rest of the team and not designed in a vacuum.
geoffs wrote:
point me in the direction of what you would consider some decent coding standard documents...
I can, but a lot of it depends on your chosen programming language. I really like the Framework Design Guidelines book. It is focused on .NET and designing public facing APIs but at least 90% of the guidelines specified apply to any language. The other one (although more for a really solid reference and background information) is the Ada 95 Quality and Style Guide. (If you can't find it, email me directly from CP and I can email it to you.) From one of my talks on this: What is a code standard?
- Encompasses all aspects of code construction
- Designed to improve program adaptation and maintenance
- Do not form an inflexible set of standards
- Consistent
- Is not “one size fits all” – different for different languages
- Defines the “best practices” for writing code for your development group
- Must adapt to changes in technology and language
What is a code standard?
- Source Code Presentation (Code Formatting)
- Readability
- Program Structure
- Programming Practices
- Concurrency
- Portability/Interoperability
- Reusability
- Performance
- Globalization
The rest of the slide deck (it's short but a lot of the slides have speaker notes) is available on my blog if you want to browse through it. Also, if you're ever in the Florida area (or any of the east coast southern states) I present at a lot of the code camps and usually have a round-table discussion on this topic.
Scott Dorman
Microsoft® MVP - Visual C# | MCPD President - Tampa Bay IASA [Blog][Articles][Forum Guidelines]
Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buc
Hi Scott - thanks for the reply and the information. I forgot to include the info about the languages we use at my location. We are mostly a C++ development group, with some C. The targets are 95% embedded environments (non-Windows) but with some Windows application work for tools (the latter also perhaps using .Net and perhaps C#). That collection of languages and environments will obviously imply their own set of guidelines, yet many coding standard guidelines also crossover the language and environment boundaries. It looks like you have put quite a bit of time into exploring these issues and I'd like to gain from your efforts. I'll be emailing you to discuss this further. I appreciate your help. I am located in the Pacific Northwest and don't make it to Florida too often, although periodically I may head over to Orlando where we also have a satellite development group and also to West Palm Beach (family). Next time I am out I may have to look you up...
-
Hans Dietrich wrote:
to them it's a job, and a clean compile is the best you can expect from them.
That pretty much sums it up. Sadly, a clean compile doesn't mean a bug free execution. "Your code looks like shit, and by the way, I can spot 5 logic errors just by looking at the code". That's what I seem to be saying a lot lately. :sigh: Marc
And if the code was CLEAN, you could spot 5 -more- logic problems...
-
If I may I add my 2c I would normally strongly encourage to have all personnel involved in development familiarised with Microsoft .NET Framework Design Guidelines. These guidelines set out naming conventions, file organisation and many other rules making the code readable and easy to maintain. There are number of resources worth reading, such as follows: 1. published by Brad Adams (founding member of both the Common Language Runtime, and .NET Framework teams) a) Microsoft Internal Coding Guidelines[^] - a good start and something I do follow myself. b) plenty of other guidelines[^] worth checking out in a free time 2. Design Guidelines for Class Library Developers on MSDN[^] 3. every now and then Krzysztof Cwalina's blog[^] is a good read too (at least it used to be) Secondly I would strongly encourage the code documentation. Whilst I do perfectly understand that documenting the code has been the bane of all programmers since the day 1 (and I also suffer from it), I believe it is imperative to write documentation. The main rule - explain NOT WHAT the code does but WHY you've written it this way. Again I would strongly encourage to make a habit of documenting (at least) all publicly exposed objects (types, classes, methods, properties etc) using XML documentation. A good start: here[^] and here[^] Because I work with .NET all of the above mainly applies to .NET stuff, yet it could still make sense for those working with other languages/technologies.
Igor - thank you for all of the resources mentioned. They will be helpful for me as I guide this committee towards a site-wide standard. Code documentation is one of the subjects very near to my heart. I am adamant about the commitment to providing it but have so far been having difficulty getting others to sign on to taking the time to do it. Some of that problem is a result of pressure from the management to get results out the door with an unrealistic scheduling, thereby pressuring the developers to feel that they must just get the logic implemented with the compromise being no time for documenting (very short-sighted but when you are between a rock and a hard place...). Happily, with some changes in management over the last year, that situation is quickly getting rectified. Personally, I always document the code. I have been using Doxygen for doing so. While not perfect, it is still pretty good. In the end, it might be necessary to have a code nazi to police the code before it gets integrated into the main development branches. The term itself sounds awful, but some people have problems conforming regardless. BTW, we do have code reviews which are helpful in the enforcement process.
-
Scott Dorman wrote: Code standards/style is one of those spaces I actually like to play in and have established them at several of the companies I've worked for.
I'm currently working for a company where coding standards are talked about but there has been no agreement on a definitive guideline. The result of this being that each person has their own way of doing things, leading to the problem that the code can be difficult to understand and maintain. It also appears that theres resistance to any move to try to standardise, the reason being that the people involved have their own opinions so we get nowhere further with the discussion. Another excuse given is theres "no time" to sort things like this out. The Question I've got for you is this; when you have implemented such standards in existing development teams, what kind of hurdles have you encountered? and how did you manage to overcome them? I'd like to see if theres an approach that could be taken to get a bunch of developers (and their managers) who are set in their own ways to agree the standard and stick to them (not that I'm in a position currently to push for this, but who knows!) Also, reaching an consensus on the standard vs someone taking responsiblity of the standards, which of these might be a better approach? Any thoughts from anyone on this are appreciated.
Billy. "Duct tape is like the force, it has a light side, a dark side and it holds the universe together!" - Anonymous my holding page..more coming soon!
I'm currently working for a company where coding standards are talked about but there has been no agreement on a definitive guideline. The result of this being that each person has their own way of doing things, leading to the problem that the code can be difficult to understand and maintain. It also appears that theres resistance to any move to try to standardise, the reason being that the people involved have their own opinions so we get nowhere further with the discussion. Another excuse given is theres "no time" to sort things like this out." This is rule by committee (aka mob). Do these people also come and go any time and any day they feel like it or are there core hours for people to be at work? If there are core hours, who set them? The answer is Management. You know: the guys that run the company. Obviously a standard should not be rammed down the throats of the workers but if all else fails, then management has to say, "This is our new coding standard. Follow it." The establishment of a standard doesn't mean it will be followed. That has be be done through the code review process which I assume is part of you development process. Reviewers should not accept code that does not conform to the standard. Peer pressure is a good tool for standards compliance. A coding standard is not a static thing. So start with a standard that doesn't cause too much backlash and then grow it. Basic hygiene issues make a good starting point. If you are using C++, rules against using some of the more dangerous C compatability features are candidates. Basic formatting and naming conventions are candidates. Things that cause problems are candidates for a new entry in the standard. There are lots of coding standards on the Internet so pick one you like, modify it to suit your situation and propose it to management. If that doesn't work, then sedition may. In every organization there is a developer that is looked up to by nearly everyone. Recruit him/her. If he/she starts to use the standard that you produced (with perhaps a few changes) in his/her own work and as a guide for code reviews then its use is likely to spread. Again, peer pressure is a good tool to promote compliance. The first objective of a coding standard is to make all the code look like it came from the same company. The second is to make it easier to read and modify. You can't build a perfect system out of defective parts. But you can keep the testers busy.
-
I'm a firm believer in the 80 column limit myself (I, too, am a code nazi). But pick a different font and you can easily print 120 columns on even the crappiest of printers. Consolas is your friend.
Perhaps I'm more age impaired than you are (eyes, you know), but I just ran a test where I printed a section of code with some lines having as much as 120 characters in them. I used Courier New as the font at point sizes of 10, 9, and 8. In addition, I changed the character spacing to be condensed by 1 point. The page was setup for 1" margins left and right (typical for a document at our site). The net result was that I was hard pressed to get even 100 columns across with the smallest point size. In addition, the readability was severely impaired because of the condensed spacing and the smaller font size. I don't think I could live with more than 80 columns for printing...
-
We don't print much code (everything is sent by email internaly and such means) but I guess you are right if that happens it isn't as readable anymore. (hadn't given it much thought untill you mentioned it, since it olmost never happens here) I'll keep that in mind and might reduce the number of cols
-
The ultimate goal is readable, understandable code with few surprises[^]. Everything in that direction helps. Clean, consistent formatting trains the subconcious to provide additional information without mental effort*: indented == new scope, lowercase = local, gets destroyed when leaving block, and so on. Working on a consistent codebase for longer time likely "looks good" / "looks bad" will be injected when looking at a block of code. That might also explain why people get worked up so much about a specific coding convention: reading another one throws them off their guard. Belowdeck, all "danger!" - signs are flashing, while the captain has to reassure the crew that "waves" are indeed a normal appearance in some waters. *) In my mental model of the programmer, we work at the edge of the "7 things one can keep in his mind at a time". Maybe to be a great developer that need to be 8. Pair Programming extends that to maybe 11. "Without mental effort", in this setting, means: not clogging up your first level cache.
-
I'm currently working for a company where coding standards are talked about but there has been no agreement on a definitive guideline. The result of this being that each person has their own way of doing things, leading to the problem that the code can be difficult to understand and maintain. It also appears that theres resistance to any move to try to standardise, the reason being that the people involved have their own opinions so we get nowhere further with the discussion. Another excuse given is theres "no time" to sort things like this out." This is rule by committee (aka mob). Do these people also come and go any time and any day they feel like it or are there core hours for people to be at work? If there are core hours, who set them? The answer is Management. You know: the guys that run the company. Obviously a standard should not be rammed down the throats of the workers but if all else fails, then management has to say, "This is our new coding standard. Follow it." The establishment of a standard doesn't mean it will be followed. That has be be done through the code review process which I assume is part of you development process. Reviewers should not accept code that does not conform to the standard. Peer pressure is a good tool for standards compliance. A coding standard is not a static thing. So start with a standard that doesn't cause too much backlash and then grow it. Basic hygiene issues make a good starting point. If you are using C++, rules against using some of the more dangerous C compatability features are candidates. Basic formatting and naming conventions are candidates. Things that cause problems are candidates for a new entry in the standard. There are lots of coding standards on the Internet so pick one you like, modify it to suit your situation and propose it to management. If that doesn't work, then sedition may. In every organization there is a developer that is looked up to by nearly everyone. Recruit him/her. If he/she starts to use the standard that you produced (with perhaps a few changes) in his/her own work and as a guide for code reviews then its use is likely to spread. Again, peer pressure is a good tool to promote compliance. The first objective of a coding standard is to make all the code look like it came from the same company. The second is to make it easier to read and modify. You can't build a perfect system out of defective parts. But you can keep the testers busy.
dilton_dalton wrote:
If that doesn't work, then sedition may. In every organization there is a developer that is looked up to by nearly everyone. Recruit him/her. If he/she starts to use the standard that you produced (with perhaps a few changes) in his/her own work and as a guide for code reviews then its use is likely to spread. Again, peer pressure is a good tool to promote compliance.
Heres the thing ... theres no formal code review process either...I had one person check my code when I started, then after that it appears we're left to our own devices, so its possible the code may get crap in it. that was last year! there no agreement on the way forward on code reviews either (it has been discussed), because people discussing how to do this are scared of hurting developers feelings and I think they're worried the rubbish will be out in the open (IMO).! also management will only do stuff if it costs nothing in terms of resource or cost, and they are quite entrenched in their ways... not sure how I can move forward with that...
dilton_dalton wrote:
If that doesn't work, then sedition may. In every organization there is a developer that is looked up to by nearly everyone. Recruit him/her. If he/she starts to use the standard that you produced (with perhaps a few changes) in his/her own work and as a guide for code reviews then its use is likely to spread. Again, peer pressure is a good tool to promote compliance.
I wish I could say that there was a long-time developer who we could "look up" to and is well respected enough for their word to matter... but the people here seem to have an indifferent attitude. One the newer guys have suggested a similar scheme where we took a section of work and said " we sohuld sit down and take a look to see how can we improve this" in a meeting, but it appears very few were interested. So there are deeper problems than this, and looks like an almost vertical struggle (cue brick wall) ...i'm obviously in the wrong place!
Billy. MCPD Windows Developer "Duct tape is like the force, it has a light side, a dark side and it holds the universe together!" - Anonymous my holding page..more coming soon!
-
:sigh: Here I expel the ultimate wisdom, the mental model on which future generations of developers will build their skills - and you vote me for the cartoon ;)
-
:sigh: Here I expel the ultimate wisdom, the mental model on which future generations of developers will build their skills - and you vote me for the cartoon ;)
-
Hi Scott - thanks for the reply and the information. I forgot to include the info about the languages we use at my location. We are mostly a C++ development group, with some C. The targets are 95% embedded environments (non-Windows) but with some Windows application work for tools (the latter also perhaps using .Net and perhaps C#). That collection of languages and environments will obviously imply their own set of guidelines, yet many coding standard guidelines also crossover the language and environment boundaries. It looks like you have put quite a bit of time into exploring these issues and I'd like to gain from your efforts. I'll be emailing you to discuss this further. I appreciate your help. I am located in the Pacific Northwest and don't make it to Florida too often, although periodically I may head over to Orlando where we also have a satellite development group and also to West Palm Beach (family). Next time I am out I may have to look you up...
You're welcome. Seeing that you are mostly a C++ group doing embedded work, a lot of the guidelines in the FDG won't apply. There are still a lot that do, however. Looking at the book, the following chapters are generic enough where they should still apply:
- Chapter 1 - Introduction
- Chapter 2 - Framework Design Fundamentals
- Chapter 3 - Naming Guidelines
The following chapters apply, but only portions of them:
- Chapter 4 - Type Design Guidelines
- Chapter 5 - Member Design
- Chapter 6 - Designing for Extensibility
Chapters 7-9 may apply, but I'm not certain of that. As you mentioned, going beyond the common aspects of the standard you will get in to guidelines that are specific to a language and/or platform. These may cover stylistic concerns (captialization in SQL for example) and may also cover functional concerns (proper use of the Dispose pattern in .NET). At this point I would definately recommend creating a set of standards that build on each other. Start with the "core" standard that defines the things that are common and incontrovertible. Then layer the language/platform specific standards on top of that as separate documents. This should allow you to keep the documents focused without becoming unwieldy. Feel free to email any time. I've been playing in this space at varying degrees over the last 15 years and I'm more than happy to share whatever experiences I've learned. If you do end up in the Orlando area definately let me know as it's only about 1.5 hours away from me (and I know the area fairly well since that's where I grew up). I'm not on the WPB side of the state too often. However, depending on where in the Pacific NW you are it seems like I'm in the Seattle area a few times a year.
Scott Dorman
Microsoft® MVP - Visual C# | MCPD President - Tampa Bay IASA [Blog][Articles][Forum Guidelines]
Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
-
Scott Dorman wrote:
You will probabbly be feeling the effects for a long time.
Well I'v managed to reduce it to one programme now that doens't need much maintenance or altering, but whenever it does I end up with headache's from hell.
Scott Dorman wrote:
Code standards/style is one of those spaces I actually like to play in and have established them at several of the companies I've worked for.
I'm now in the process of doing the same for a client of us so I guess I'm heading the same direction as you, but I'm shure I'm just a noob in comparison ;P
Tom deketelaere wrote:
Well I'v managed to reduce it to one programme now that doens't need much maintenance or altering, but whenever it does I end up with headache's from hell.
At least it sounds like you've managed to isolate it fairly well.
Tom deketelaere wrote:
I'm now in the process of doing the same for a client of us so I guess I'm heading the same direction as you, but I'm shure I'm just a noob in comparison ;P
Feel free to email any time. I've been playing in this space at varying degrees over the last 15 years and I'm more than happy to share whatever experiences I've learned. I really like the Framework Design Guidelines book. It is focused on .NET and designing public facing APIs but at least 90% of the guidelines specified apply to any language. The other one (although more for a really solid reference and background information) is the Ada 95 Quality and Style Guide. (If you can't find it, email me directly from CP and I can email it to you.) There is also a slide deck (it's short but a lot of the slides have speaker notes) available on my blog from the round-table discussion I usually run on this topic if you want to browse through it. (Go to my public SkyDrive folder link.)
Scott Dorman
Microsoft® MVP - Visual C# | MCPD President - Tampa Bay IASA [Blog][Articles][Forum Guidelines]
Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
-
Scott Dorman wrote: Code standards/style is one of those spaces I actually like to play in and have established them at several of the companies I've worked for.
I'm currently working for a company where coding standards are talked about but there has been no agreement on a definitive guideline. The result of this being that each person has their own way of doing things, leading to the problem that the code can be difficult to understand and maintain. It also appears that theres resistance to any move to try to standardise, the reason being that the people involved have their own opinions so we get nowhere further with the discussion. Another excuse given is theres "no time" to sort things like this out. The Question I've got for you is this; when you have implemented such standards in existing development teams, what kind of hurdles have you encountered? and how did you manage to overcome them? I'd like to see if theres an approach that could be taken to get a bunch of developers (and their managers) who are set in their own ways to agree the standard and stick to them (not that I'm in a position currently to push for this, but who knows!) Also, reaching an consensus on the standard vs someone taking responsiblity of the standards, which of these might be a better approach? Any thoughts from anyone on this are appreciated.
Billy. "Duct tape is like the force, it has a light side, a dark side and it holds the universe together!" - Anonymous my holding page..more coming soon!
williamFalconerUK wrote:
I'm currently working for a company where coding standards are talked about but there has been no agreement on a definitive guideline. The result of this being that each person has their own way of doing things, leading to the problem that the code can be difficult to understand and maintain. It also appears that theres resistance to any move to try to standardise, the reason being that the people involved have their own opinions so we get nowhere further with the discussion. Another excuse given is theres "no time" to sort things like this out.
Those are certainly some common problems.
williamFalconerUK wrote:
when you have implemented such standards in existing development teams, what kind of hurdles have you encountered? and how did you manage to overcome them? I'd like to see if theres an approach that could be taken to get a bunch of developers (and their managers) who are set in their own ways to agree the standard and stick to them (not that I'm in a position currently to push for this, but who knows!)
You already hit on some, but adding to that...there are a lot of different problems you can (and probably will) run in to depending on the size and makeup of the team. Each person feeling that "their way is best" and being resistant to change are the most common from the development team. The best way to overcome this is to get them involved in the decision making process and keep things small. Don't have one long meeting where you try to reach consensus for the entire standard. Instead, break it up into smaller more focused meetings. This is espcially important if you want to deal with the "holy war" type issues (things like curly brace placement, tab sizes, etc.) For those issues (and any issue that generates a lot of heated debate) the best approach I have found is to sit quietly in the room and let the two sides argue for a bit (no more than an hour). Eventually everyone will become so tired of the back and forth that you can step in and suggest a compromise based on what you heard from both sides. That's the key - you need to make both sides understand that you have been listening to the entire argument, that you see the benefits in both options and that you aren't taking sides but merely suggesting a compromise. This doesn't always work but it is relatively effective. When it doesn't work sometimes you either have to mandate a guideline or decide tha
-
I take care to ensure the aesthetics of my code. That spacing and formatting is consistent. I don't care if I'm writing throw away code or production code. The code should always look neat and tidy. Why don't other programmers do the same??? OK, I'm sure there are some out there. And yes, there are code beautifiers, so who really cares, right? What's your thoughts on whether code should look good, in terms of spacing, formatting, structure, etc.? Marc
I think I've yet to meet three programmers on a team who all agree on what aesthetics are. consistent yes, within one coder's code. Which is practically useless. I find algorithm complexity to be far more beautiful than the spacing in the original code- but then again, I can READ CODE, rather than READ COMMENTS. Having said that- you'll always find indentation in my code, because I specifically find I have a problem with remembering to close multi-line groups. Other than that- well, that's all personal aesthetics, and asethetics are *always* subjective.
-
williamFalconerUK wrote:
I'm currently working for a company where coding standards are talked about but there has been no agreement on a definitive guideline. The result of this being that each person has their own way of doing things, leading to the problem that the code can be difficult to understand and maintain. It also appears that theres resistance to any move to try to standardise, the reason being that the people involved have their own opinions so we get nowhere further with the discussion. Another excuse given is theres "no time" to sort things like this out.
Those are certainly some common problems.
williamFalconerUK wrote:
when you have implemented such standards in existing development teams, what kind of hurdles have you encountered? and how did you manage to overcome them? I'd like to see if theres an approach that could be taken to get a bunch of developers (and their managers) who are set in their own ways to agree the standard and stick to them (not that I'm in a position currently to push for this, but who knows!)
You already hit on some, but adding to that...there are a lot of different problems you can (and probably will) run in to depending on the size and makeup of the team. Each person feeling that "their way is best" and being resistant to change are the most common from the development team. The best way to overcome this is to get them involved in the decision making process and keep things small. Don't have one long meeting where you try to reach consensus for the entire standard. Instead, break it up into smaller more focused meetings. This is espcially important if you want to deal with the "holy war" type issues (things like curly brace placement, tab sizes, etc.) For those issues (and any issue that generates a lot of heated debate) the best approach I have found is to sit quietly in the room and let the two sides argue for a bit (no more than an hour). Eventually everyone will become so tired of the back and forth that you can step in and suggest a compromise based on what you heard from both sides. That's the key - you need to make both sides understand that you have been listening to the entire argument, that you see the benefits in both options and that you aren't taking sides but merely suggesting a compromise. This doesn't always work but it is relatively effective. When it doesn't work sometimes you either have to mandate a guideline or decide tha
Scott, Pretty much you've hit the nail on the head. And you've given some good arguments to take away and use to help things along...
Scott Dorman wrote:
Eventually everyone will become so tired of the back and forth that you can step in and suggest a compromise based on what you heard from both sides. That's the key - you need to make both sides understand that you have been listening to the entire argument, that you see the benefits in both options and that you aren't taking sides but merely suggesting a compromise.
I'm pretty much more of a listener in these things than a talker so what you suggest might be the move that could be made, specially considering the arguments are of the "holy war" type you speak of, and they do end up getting nowhere.
Scott Dorman wrote:
Getting buy-in from the developers is usually easier than getting buy-in from management. Managements arguement is almost always "we don't have the time/resources/budget to spend", which is usually the case. However, you need to be able to show that by not having a standard in place it is harder to transition people from one project to another, harder to diagnose and correct problems, and ultimately leads to a less stable code base. This is, of course, almost all subjective as it is difficult to actually put numbers to any of these concepts.
As for the management thing, I think I'll have the opportunity to talk about this and the other concerns I have with them as a review is coming up. if that doesn't work then maybe one of the other approaches need to be taken.
Scott Dorman wrote:
It usually ends up being a combination. Some things can be defined by one person and then presented to the team; others will need consensus or at least involvment from other people on the team. This is especially important if you have "entrenched" developers who are very resistant to change. By getting them involved, they feel they are being given a voice and included in the process. Sometimes that's all it takes to get them to open up and embrace the new ideas.
This may well be the way forward, if no one else takes the lead, then maybe with the right prep, good information under my belt and a good presentation I could do it...and involvement from the team certainly will help! Once again i'll take all the advice on board, so thanks! :) Also if anyone knows of any good
-
Perhaps I'm more age impaired than you are (eyes, you know), but I just ran a test where I printed a section of code with some lines having as much as 120 characters in them. I used Courier New as the font at point sizes of 10, 9, and 8. In addition, I changed the character spacing to be condensed by 1 point. The page was setup for 1" margins left and right (typical for a document at our site). The net result was that I was hard pressed to get even 100 columns across with the smallest point size. In addition, the readability was severely impaired because of the condensed spacing and the smaller font size. I don't think I could live with more than 80 columns for printing...
Ah, 1 inch margins... An inch will fit about 10 chars so that's where the 20 went. I just tested the crappy ole hp laserjet we got here at work. With no margins, Consolas 8 will give you 129 columns by 81 rows. But like I said, I'm with you. 80 columns is best. That way there's PLENTY of room on the right to scribble notes. I mean, you can stare at the screen only so long ... before you go insaaaaane
-
I can only see about 100 columns (in VS, using 1 screen) CRT's FTW though, they're the only kind of screen that doesn't give me a headache (anyone else have this problem?)
harold aptroot wrote:
give me a headache
My other half has the same problem, the place she used to work did a company-wide rollout of new LCDs as the new standard issue equipment & she just couldn't work on one. Headache would build up over the course of a day & take days to go away. At home we bought a 46" Bravia X which we had to take back too 'coz she couldn't watch it :(( . Luckily, we were able to do a straight-out swap for a Panasonic Viera 50" :-D .
T-Mac-Oz "When I'm ruler of the universe ... I'm working on it, I'm working on it. I'm just as frustrated as you are. It turns out to be a non-trivial problem." - Linus Torvalds
-
:laugh: I want a shortcut for adding it to code that does not use it!
John
Vikram A Punathambekar wrote:
I wish VS had a similar shortcut for stripping out Hungarian notation!
Take out the annoying MS "redundant data type - already known from declaration" Hungarian
John M. Drescher wrote:
I want a shortcut for adding it to code that does not use it!
And put in the proper "this prefix indicates how the variable is expected to be used" Hungarian?
T-Mac-Oz "When I'm ruler of the universe ... I'm working on it, I'm working on it. I'm just as frustrated as you are. It turns out to be a non-trivial problem." - Linus Torvalds
