Unexciting Coding [modified]
-
I'm sitting here at home, waiting for the DirecTV guy to show up, and thought I'd work on some code for a new article I'm writing... Writing code for a CodeProject article is fun, and can be quite fast when you make certain assumptions about the objects being used and data being manipulated. Once you get it working, you think, "Ahhh, it's almost ready to release." Of course, my desire to release the code is almost always tempered with a desire to make it self-documenting and somewhat bulletproof. Adding comments and exception handling is tedious drudgery - something I equate to ditch-digging, yet it needs to be done. You have to be a philosopher (no matter what you do, it seems like it's never enough) and a clairvoyant (anyone using this code might try this or that) to perform this task effectively. I've been working for three hours, and I've only covered two classes. In the end, it's a pain in the ass, but I bolster my attitude knowing that even if my efforts might not be appreciated by a single person, I'll be able to maintain the code properly in the future. I have advice for anyone just starting out as a programmer, regardless of the language or platform you're targeting: 0) ALWAYS comment your code. It's best to do it as you go, or at least once you've completed the bulk of an object's code. If you don't comment as you go, you probably won't have time to go back and rectify the situation. Being lazy up front causes maintenance problems down the road. 1) Never assume that someone knows what you were thinking. If there is ANY question about your intentions, document it in comments. 2) Don't be afraid to be verbose. Partial sentences can sometimes convey an incorrect perception of what the code is doing, and why it's doing it. Comments do NOT cost anything as far as the compiled size/speed of your assemblies are concerned. 3) In the case of Microsoft tools, Make appropriate comments within the Intellisense system. There is NOTHING that pisses me off more than trying to use an object and finding out through trial and error that a property is read-only. 4) USE COMPLETE WORDS! Code commenting is not a valid "texting" environment. Using things like "Ur", or "plz" just pisses off the adults. 5) Every property delegate, constructor, and method should have an Intellisense comment. 6) Make it a practice to appropriately comment your own personal code, and you'll find it easier to do in code you write for your employer/customer. 7) If there is a possibility that another progra
-
I'm sitting here at home, waiting for the DirecTV guy to show up, and thought I'd work on some code for a new article I'm writing... Writing code for a CodeProject article is fun, and can be quite fast when you make certain assumptions about the objects being used and data being manipulated. Once you get it working, you think, "Ahhh, it's almost ready to release." Of course, my desire to release the code is almost always tempered with a desire to make it self-documenting and somewhat bulletproof. Adding comments and exception handling is tedious drudgery - something I equate to ditch-digging, yet it needs to be done. You have to be a philosopher (no matter what you do, it seems like it's never enough) and a clairvoyant (anyone using this code might try this or that) to perform this task effectively. I've been working for three hours, and I've only covered two classes. In the end, it's a pain in the ass, but I bolster my attitude knowing that even if my efforts might not be appreciated by a single person, I'll be able to maintain the code properly in the future. I have advice for anyone just starting out as a programmer, regardless of the language or platform you're targeting: 0) ALWAYS comment your code. It's best to do it as you go, or at least once you've completed the bulk of an object's code. If you don't comment as you go, you probably won't have time to go back and rectify the situation. Being lazy up front causes maintenance problems down the road. 1) Never assume that someone knows what you were thinking. If there is ANY question about your intentions, document it in comments. 2) Don't be afraid to be verbose. Partial sentences can sometimes convey an incorrect perception of what the code is doing, and why it's doing it. Comments do NOT cost anything as far as the compiled size/speed of your assemblies are concerned. 3) In the case of Microsoft tools, Make appropriate comments within the Intellisense system. There is NOTHING that pisses me off more than trying to use an object and finding out through trial and error that a property is read-only. 4) USE COMPLETE WORDS! Code commenting is not a valid "texting" environment. Using things like "Ur", or "plz" just pisses off the adults. 5) Every property delegate, constructor, and method should have an Intellisense comment. 6) Make it a practice to appropriately comment your own personal code, and you'll find it easier to do in code you write for your employer/customer. 7) If there is a possibility that another progra
I gave you the one vote as a joke to prepare you for releasing the article :p
Need software developed? Offering C# development all over the United States, ERL GLOBAL, Inc is the only call you will have to make.
Happiness in intelligent people is the rarest thing I know. -- Ernest Hemingway
Most of this sig is for Google, not ego. -
I'm sitting here at home, waiting for the DirecTV guy to show up, and thought I'd work on some code for a new article I'm writing... Writing code for a CodeProject article is fun, and can be quite fast when you make certain assumptions about the objects being used and data being manipulated. Once you get it working, you think, "Ahhh, it's almost ready to release." Of course, my desire to release the code is almost always tempered with a desire to make it self-documenting and somewhat bulletproof. Adding comments and exception handling is tedious drudgery - something I equate to ditch-digging, yet it needs to be done. You have to be a philosopher (no matter what you do, it seems like it's never enough) and a clairvoyant (anyone using this code might try this or that) to perform this task effectively. I've been working for three hours, and I've only covered two classes. In the end, it's a pain in the ass, but I bolster my attitude knowing that even if my efforts might not be appreciated by a single person, I'll be able to maintain the code properly in the future. I have advice for anyone just starting out as a programmer, regardless of the language or platform you're targeting: 0) ALWAYS comment your code. It's best to do it as you go, or at least once you've completed the bulk of an object's code. If you don't comment as you go, you probably won't have time to go back and rectify the situation. Being lazy up front causes maintenance problems down the road. 1) Never assume that someone knows what you were thinking. If there is ANY question about your intentions, document it in comments. 2) Don't be afraid to be verbose. Partial sentences can sometimes convey an incorrect perception of what the code is doing, and why it's doing it. Comments do NOT cost anything as far as the compiled size/speed of your assemblies are concerned. 3) In the case of Microsoft tools, Make appropriate comments within the Intellisense system. There is NOTHING that pisses me off more than trying to use an object and finding out through trial and error that a property is read-only. 4) USE COMPLETE WORDS! Code commenting is not a valid "texting" environment. Using things like "Ur", or "plz" just pisses off the adults. 5) Every property delegate, constructor, and method should have an Intellisense comment. 6) Make it a practice to appropriately comment your own personal code, and you'll find it easier to do in code you write for your employer/customer. 7) If there is a possibility that another progra
By offering good advices and useful code for free you are chipping a bit off your bad-ass aura, but thanks anyway! ;)
-
I'm sitting here at home, waiting for the DirecTV guy to show up, and thought I'd work on some code for a new article I'm writing... Writing code for a CodeProject article is fun, and can be quite fast when you make certain assumptions about the objects being used and data being manipulated. Once you get it working, you think, "Ahhh, it's almost ready to release." Of course, my desire to release the code is almost always tempered with a desire to make it self-documenting and somewhat bulletproof. Adding comments and exception handling is tedious drudgery - something I equate to ditch-digging, yet it needs to be done. You have to be a philosopher (no matter what you do, it seems like it's never enough) and a clairvoyant (anyone using this code might try this or that) to perform this task effectively. I've been working for three hours, and I've only covered two classes. In the end, it's a pain in the ass, but I bolster my attitude knowing that even if my efforts might not be appreciated by a single person, I'll be able to maintain the code properly in the future. I have advice for anyone just starting out as a programmer, regardless of the language or platform you're targeting: 0) ALWAYS comment your code. It's best to do it as you go, or at least once you've completed the bulk of an object's code. If you don't comment as you go, you probably won't have time to go back and rectify the situation. Being lazy up front causes maintenance problems down the road. 1) Never assume that someone knows what you were thinking. If there is ANY question about your intentions, document it in comments. 2) Don't be afraid to be verbose. Partial sentences can sometimes convey an incorrect perception of what the code is doing, and why it's doing it. Comments do NOT cost anything as far as the compiled size/speed of your assemblies are concerned. 3) In the case of Microsoft tools, Make appropriate comments within the Intellisense system. There is NOTHING that pisses me off more than trying to use an object and finding out through trial and error that a property is read-only. 4) USE COMPLETE WORDS! Code commenting is not a valid "texting" environment. Using things like "Ur", or "plz" just pisses off the adults. 5) Every property delegate, constructor, and method should have an Intellisense comment. 6) Make it a practice to appropriately comment your own personal code, and you'll find it easier to do in code you write for your employer/customer. 7) If there is a possibility that another progra
Wow, with only a few minor touch-ups, you could take that post and submit it as an article! My suggestion for a title: Enterprise Cloud Computing with Lookahead Cache. :)
Best wishes, Hans
[CodeProject Forum Guidelines] [How To Ask A Question] [My Articles]
-
I gave you the one vote as a joke to prepare you for releasing the article :p
Need software developed? Offering C# development all over the United States, ERL GLOBAL, Inc is the only call you will have to make.
Happiness in intelligent people is the rarest thing I know. -- Ernest Hemingway
Most of this sig is for Google, not ego. -
I gave you the one vote as a joke to prepare you for releasing the article :p
Need software developed? Offering C# development all over the United States, ERL GLOBAL, Inc is the only call you will have to make.
Happiness in intelligent people is the rarest thing I know. -- Ernest Hemingway
Most of this sig is for Google, not ego.I appreciate the spirit in which you made your vote. NOW FIX IT. :)
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001 -
By offering good advices and useful code for free you are chipping a bit off your bad-ass aura, but thanks anyway! ;)
I don't think so. I counted to infinity this morning (.02 seconds to do), and I followed that up by killing someone that was simply walking past my house. It's only 8:15am, and I've already had a very full day.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001 -
I appreciate the spirit in which you made your vote. NOW FIX IT. :)
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001Ok, but only since you demanded.
Need software developed? Offering C# development all over the United States, ERL GLOBAL, Inc is the only call you will have to make.
Happiness in intelligent people is the rarest thing I know. -- Ernest Hemingway
Most of this sig is for Google, not ego. -
I'm sitting here at home, waiting for the DirecTV guy to show up, and thought I'd work on some code for a new article I'm writing... Writing code for a CodeProject article is fun, and can be quite fast when you make certain assumptions about the objects being used and data being manipulated. Once you get it working, you think, "Ahhh, it's almost ready to release." Of course, my desire to release the code is almost always tempered with a desire to make it self-documenting and somewhat bulletproof. Adding comments and exception handling is tedious drudgery - something I equate to ditch-digging, yet it needs to be done. You have to be a philosopher (no matter what you do, it seems like it's never enough) and a clairvoyant (anyone using this code might try this or that) to perform this task effectively. I've been working for three hours, and I've only covered two classes. In the end, it's a pain in the ass, but I bolster my attitude knowing that even if my efforts might not be appreciated by a single person, I'll be able to maintain the code properly in the future. I have advice for anyone just starting out as a programmer, regardless of the language or platform you're targeting: 0) ALWAYS comment your code. It's best to do it as you go, or at least once you've completed the bulk of an object's code. If you don't comment as you go, you probably won't have time to go back and rectify the situation. Being lazy up front causes maintenance problems down the road. 1) Never assume that someone knows what you were thinking. If there is ANY question about your intentions, document it in comments. 2) Don't be afraid to be verbose. Partial sentences can sometimes convey an incorrect perception of what the code is doing, and why it's doing it. Comments do NOT cost anything as far as the compiled size/speed of your assemblies are concerned. 3) In the case of Microsoft tools, Make appropriate comments within the Intellisense system. There is NOTHING that pisses me off more than trying to use an object and finding out through trial and error that a property is read-only. 4) USE COMPLETE WORDS! Code commenting is not a valid "texting" environment. Using things like "Ur", or "plz" just pisses off the adults. 5) Every property delegate, constructor, and method should have an Intellisense comment. 6) Make it a practice to appropriately comment your own personal code, and you'll find it easier to do in code you write for your employer/customer. 7) If there is a possibility that another progra
John Simmons / outlaw programmer wrote:
- Never assume that someone knows what you were thinking.
John Simmons / outlaw programmer wrote:
- Don't be afraid to be verbose.
John Simmons / outlaw programmer wrote:
- USE COMPLETE WORDS! Code commenting is not a valid "texting" environment. Using things like "Ur", or "plz" just pisses off the adults.
These points go well to be presented to the ones who ask questions in the programming forums too. Especially #1 - I can't explain how it feels like when someone says this: "It is not working... Plz help". Breaking the rules #1) #2) and #4) together in a single post.
It is a crappy thing, but it's life -^ Carlo Pallini
-
I don't think so. I counted to infinity this morning (.02 seconds to do), and I followed that up by killing someone that was simply walking past my house. It's only 8:15am, and I've already had a very full day.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001So all in all a slow day, huh?
¡El diablo está en mis pantalones! ¡Mire, mire! Real Mentats use only 100% pure, unfooled around with Sapho Juice(tm)! SELECT * FROM User WHERE Clue > 0 0 rows returned Save an Orange - Use the VCF! VCF Blog
-
Ok, but only since you demanded.
Need software developed? Offering C# development all over the United States, ERL GLOBAL, Inc is the only call you will have to make.
Happiness in intelligent people is the rarest thing I know. -- Ernest Hemingway
Most of this sig is for Google, not ego.Didn't he forget to say PLZ? :rolleyes:
-
I'm sitting here at home, waiting for the DirecTV guy to show up, and thought I'd work on some code for a new article I'm writing... Writing code for a CodeProject article is fun, and can be quite fast when you make certain assumptions about the objects being used and data being manipulated. Once you get it working, you think, "Ahhh, it's almost ready to release." Of course, my desire to release the code is almost always tempered with a desire to make it self-documenting and somewhat bulletproof. Adding comments and exception handling is tedious drudgery - something I equate to ditch-digging, yet it needs to be done. You have to be a philosopher (no matter what you do, it seems like it's never enough) and a clairvoyant (anyone using this code might try this or that) to perform this task effectively. I've been working for three hours, and I've only covered two classes. In the end, it's a pain in the ass, but I bolster my attitude knowing that even if my efforts might not be appreciated by a single person, I'll be able to maintain the code properly in the future. I have advice for anyone just starting out as a programmer, regardless of the language or platform you're targeting: 0) ALWAYS comment your code. It's best to do it as you go, or at least once you've completed the bulk of an object's code. If you don't comment as you go, you probably won't have time to go back and rectify the situation. Being lazy up front causes maintenance problems down the road. 1) Never assume that someone knows what you were thinking. If there is ANY question about your intentions, document it in comments. 2) Don't be afraid to be verbose. Partial sentences can sometimes convey an incorrect perception of what the code is doing, and why it's doing it. Comments do NOT cost anything as far as the compiled size/speed of your assemblies are concerned. 3) In the case of Microsoft tools, Make appropriate comments within the Intellisense system. There is NOTHING that pisses me off more than trying to use an object and finding out through trial and error that a property is read-only. 4) USE COMPLETE WORDS! Code commenting is not a valid "texting" environment. Using things like "Ur", or "plz" just pisses off the adults. 5) Every property delegate, constructor, and method should have an Intellisense comment. 6) Make it a practice to appropriately comment your own personal code, and you'll find it easier to do in code you write for your employer/customer. 7) If there is a possibility that another progra
John Simmons / outlaw programmer wrote:
Don't be afraid to be verbose. Partial sentences can sometimes convey an incorrect perception of what the code is doing, and why it's doing it. Comments do NOT cost anything as far as the compiled size/speed of your assemblies are concerned
We once got a developer who removed spaces, comments, line-breaks etc... because it would make the dll smaller :doh:. luckily for me, I do most of the above :-)
V.
Stop smoking so you can: Enjoy longer the money you save. Moviereview Archive -
I'm sitting here at home, waiting for the DirecTV guy to show up, and thought I'd work on some code for a new article I'm writing... Writing code for a CodeProject article is fun, and can be quite fast when you make certain assumptions about the objects being used and data being manipulated. Once you get it working, you think, "Ahhh, it's almost ready to release." Of course, my desire to release the code is almost always tempered with a desire to make it self-documenting and somewhat bulletproof. Adding comments and exception handling is tedious drudgery - something I equate to ditch-digging, yet it needs to be done. You have to be a philosopher (no matter what you do, it seems like it's never enough) and a clairvoyant (anyone using this code might try this or that) to perform this task effectively. I've been working for three hours, and I've only covered two classes. In the end, it's a pain in the ass, but I bolster my attitude knowing that even if my efforts might not be appreciated by a single person, I'll be able to maintain the code properly in the future. I have advice for anyone just starting out as a programmer, regardless of the language or platform you're targeting: 0) ALWAYS comment your code. It's best to do it as you go, or at least once you've completed the bulk of an object's code. If you don't comment as you go, you probably won't have time to go back and rectify the situation. Being lazy up front causes maintenance problems down the road. 1) Never assume that someone knows what you were thinking. If there is ANY question about your intentions, document it in comments. 2) Don't be afraid to be verbose. Partial sentences can sometimes convey an incorrect perception of what the code is doing, and why it's doing it. Comments do NOT cost anything as far as the compiled size/speed of your assemblies are concerned. 3) In the case of Microsoft tools, Make appropriate comments within the Intellisense system. There is NOTHING that pisses me off more than trying to use an object and finding out through trial and error that a property is read-only. 4) USE COMPLETE WORDS! Code commenting is not a valid "texting" environment. Using things like "Ur", or "plz" just pisses off the adults. 5) Every property delegate, constructor, and method should have an Intellisense comment. 6) Make it a practice to appropriately comment your own personal code, and you'll find it easier to do in code you write for your employer/customer. 7) If there is a possibility that another progra
Hear hear. That's probably the best thing about projecting code; you get an opportunity to go back and do all that stuff.
-
I don't think so. I counted to infinity this morning (.02 seconds to do), and I followed that up by killing someone that was simply walking past my house. It's only 8:15am, and I've already had a very full day.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001 -
I often wondered if Chuck Norris had a love child...
Visit http://www.notreadytogiveup.com/[^] and do something special today.
There was no love involved.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001 -
I'm sitting here at home, waiting for the DirecTV guy to show up, and thought I'd work on some code for a new article I'm writing... Writing code for a CodeProject article is fun, and can be quite fast when you make certain assumptions about the objects being used and data being manipulated. Once you get it working, you think, "Ahhh, it's almost ready to release." Of course, my desire to release the code is almost always tempered with a desire to make it self-documenting and somewhat bulletproof. Adding comments and exception handling is tedious drudgery - something I equate to ditch-digging, yet it needs to be done. You have to be a philosopher (no matter what you do, it seems like it's never enough) and a clairvoyant (anyone using this code might try this or that) to perform this task effectively. I've been working for three hours, and I've only covered two classes. In the end, it's a pain in the ass, but I bolster my attitude knowing that even if my efforts might not be appreciated by a single person, I'll be able to maintain the code properly in the future. I have advice for anyone just starting out as a programmer, regardless of the language or platform you're targeting: 0) ALWAYS comment your code. It's best to do it as you go, or at least once you've completed the bulk of an object's code. If you don't comment as you go, you probably won't have time to go back and rectify the situation. Being lazy up front causes maintenance problems down the road. 1) Never assume that someone knows what you were thinking. If there is ANY question about your intentions, document it in comments. 2) Don't be afraid to be verbose. Partial sentences can sometimes convey an incorrect perception of what the code is doing, and why it's doing it. Comments do NOT cost anything as far as the compiled size/speed of your assemblies are concerned. 3) In the case of Microsoft tools, Make appropriate comments within the Intellisense system. There is NOTHING that pisses me off more than trying to use an object and finding out through trial and error that a property is read-only. 4) USE COMPLETE WORDS! Code commenting is not a valid "texting" environment. Using things like "Ur", or "plz" just pisses off the adults. 5) Every property delegate, constructor, and method should have an Intellisense comment. 6) Make it a practice to appropriately comment your own personal code, and you'll find it easier to do in code you write for your employer/customer. 7) If there is a possibility that another progra
John Simmons / outlaw programmer wrote:
It took me 40 minutes to type/edit/re-edit/re-edit this message, but I'm finished preaching, and I now return you to your regularly scheduled chaos.
I was concerned that someone had abducted our surly friendly local neighborhood curmudgeon, until I read that line. Crisis averted.
Software Zen:
delete this; -
I'm sitting here at home, waiting for the DirecTV guy to show up, and thought I'd work on some code for a new article I'm writing... Writing code for a CodeProject article is fun, and can be quite fast when you make certain assumptions about the objects being used and data being manipulated. Once you get it working, you think, "Ahhh, it's almost ready to release." Of course, my desire to release the code is almost always tempered with a desire to make it self-documenting and somewhat bulletproof. Adding comments and exception handling is tedious drudgery - something I equate to ditch-digging, yet it needs to be done. You have to be a philosopher (no matter what you do, it seems like it's never enough) and a clairvoyant (anyone using this code might try this or that) to perform this task effectively. I've been working for three hours, and I've only covered two classes. In the end, it's a pain in the ass, but I bolster my attitude knowing that even if my efforts might not be appreciated by a single person, I'll be able to maintain the code properly in the future. I have advice for anyone just starting out as a programmer, regardless of the language or platform you're targeting: 0) ALWAYS comment your code. It's best to do it as you go, or at least once you've completed the bulk of an object's code. If you don't comment as you go, you probably won't have time to go back and rectify the situation. Being lazy up front causes maintenance problems down the road. 1) Never assume that someone knows what you were thinking. If there is ANY question about your intentions, document it in comments. 2) Don't be afraid to be verbose. Partial sentences can sometimes convey an incorrect perception of what the code is doing, and why it's doing it. Comments do NOT cost anything as far as the compiled size/speed of your assemblies are concerned. 3) In the case of Microsoft tools, Make appropriate comments within the Intellisense system. There is NOTHING that pisses me off more than trying to use an object and finding out through trial and error that a property is read-only. 4) USE COMPLETE WORDS! Code commenting is not a valid "texting" environment. Using things like "Ur", or "plz" just pisses off the adults. 5) Every property delegate, constructor, and method should have an Intellisense comment. 6) Make it a practice to appropriately comment your own personal code, and you'll find it easier to do in code you write for your employer/customer. 7) If there is a possibility that another progra
Excellent advice, John!
John Simmons / outlaw programmer wrote:
be a mentor before you have a student, because you're expected to lead by example.
That should be a t-shirt... :-D
"A Journey of a Thousand Rest Stops Begins with a Single Movement"
-
I'm sitting here at home, waiting for the DirecTV guy to show up, and thought I'd work on some code for a new article I'm writing... Writing code for a CodeProject article is fun, and can be quite fast when you make certain assumptions about the objects being used and data being manipulated. Once you get it working, you think, "Ahhh, it's almost ready to release." Of course, my desire to release the code is almost always tempered with a desire to make it self-documenting and somewhat bulletproof. Adding comments and exception handling is tedious drudgery - something I equate to ditch-digging, yet it needs to be done. You have to be a philosopher (no matter what you do, it seems like it's never enough) and a clairvoyant (anyone using this code might try this or that) to perform this task effectively. I've been working for three hours, and I've only covered two classes. In the end, it's a pain in the ass, but I bolster my attitude knowing that even if my efforts might not be appreciated by a single person, I'll be able to maintain the code properly in the future. I have advice for anyone just starting out as a programmer, regardless of the language or platform you're targeting: 0) ALWAYS comment your code. It's best to do it as you go, or at least once you've completed the bulk of an object's code. If you don't comment as you go, you probably won't have time to go back and rectify the situation. Being lazy up front causes maintenance problems down the road. 1) Never assume that someone knows what you were thinking. If there is ANY question about your intentions, document it in comments. 2) Don't be afraid to be verbose. Partial sentences can sometimes convey an incorrect perception of what the code is doing, and why it's doing it. Comments do NOT cost anything as far as the compiled size/speed of your assemblies are concerned. 3) In the case of Microsoft tools, Make appropriate comments within the Intellisense system. There is NOTHING that pisses me off more than trying to use an object and finding out through trial and error that a property is read-only. 4) USE COMPLETE WORDS! Code commenting is not a valid "texting" environment. Using things like "Ur", or "plz" just pisses off the adults. 5) Every property delegate, constructor, and method should have an Intellisense comment. 6) Make it a practice to appropriately comment your own personal code, and you'll find it easier to do in code you write for your employer/customer. 7) If there is a possibility that another progra
So, how did the DirecTv installation go? How many coax lines did the DVR require? Oh yeah, nice rant. Too bad my company's coding standards pretty much forbid everything you mentioned.
My mind is like an aluminum trap. Some things get caught in the trap, and some things bend the trap and get away.
-
I'm sitting here at home, waiting for the DirecTV guy to show up, and thought I'd work on some code for a new article I'm writing... Writing code for a CodeProject article is fun, and can be quite fast when you make certain assumptions about the objects being used and data being manipulated. Once you get it working, you think, "Ahhh, it's almost ready to release." Of course, my desire to release the code is almost always tempered with a desire to make it self-documenting and somewhat bulletproof. Adding comments and exception handling is tedious drudgery - something I equate to ditch-digging, yet it needs to be done. You have to be a philosopher (no matter what you do, it seems like it's never enough) and a clairvoyant (anyone using this code might try this or that) to perform this task effectively. I've been working for three hours, and I've only covered two classes. In the end, it's a pain in the ass, but I bolster my attitude knowing that even if my efforts might not be appreciated by a single person, I'll be able to maintain the code properly in the future. I have advice for anyone just starting out as a programmer, regardless of the language or platform you're targeting: 0) ALWAYS comment your code. It's best to do it as you go, or at least once you've completed the bulk of an object's code. If you don't comment as you go, you probably won't have time to go back and rectify the situation. Being lazy up front causes maintenance problems down the road. 1) Never assume that someone knows what you were thinking. If there is ANY question about your intentions, document it in comments. 2) Don't be afraid to be verbose. Partial sentences can sometimes convey an incorrect perception of what the code is doing, and why it's doing it. Comments do NOT cost anything as far as the compiled size/speed of your assemblies are concerned. 3) In the case of Microsoft tools, Make appropriate comments within the Intellisense system. There is NOTHING that pisses me off more than trying to use an object and finding out through trial and error that a property is read-only. 4) USE COMPLETE WORDS! Code commenting is not a valid "texting" environment. Using things like "Ur", or "plz" just pisses off the adults. 5) Every property delegate, constructor, and method should have an Intellisense comment. 6) Make it a practice to appropriately comment your own personal code, and you'll find it easier to do in code you write for your employer/customer. 7) If there is a possibility that another progra
Don't bore us with your problems! :~
Simply Elegant Designs JimmyRopes Designs
Think inside the box! ProActive Secure Systems
I'm on-line therefore I am. JimmyRopes -
So, how did the DirecTv installation go? How many coax lines did the DVR require? Oh yeah, nice rant. Too bad my company's coding standards pretty much forbid everything you mentioned.
My mind is like an aluminum trap. Some things get caught in the trap, and some things bend the trap and get away.
FyreWyrm wrote:
Too bad my company's coding standards pretty much forbid everything you mentioned.
You're working for idiots. Find a better job with smarter mentors - quick, before you're ruined for life. :doh:
"A Journey of a Thousand Rest Stops Begins with a Single Movement"