|
This is a no brainer.
Unfortunately, you are right.
I've seen this type abuse all too often 
|
|
|
|
|
Destiny777 wrote: Document your source code with loads of Comments that describe things such as what the code does and on subroutines / functions tell what is coming into that code and what is returned.
That's some of the worst coding advice you can give!
I've said it many times before (and a lot of people still disagree, which is fine), comments are evil[^]!
In my life I've never ever seen a comment that actually helped me.
I really hate comments, maybe even more so than HTML and CSS, and man do I hate HTML and CSS 
You mention testing, but not automated testing. Equally important 
|
|
|
|
|
I agree, I've been a C# development for 9 years now and I've seen far more useless, misleading or just plain wrong comments in code than helpful ones. Adding comments is just another piece of "technical debt" that needs to be maintained with the code - and devs don't see comments as important as code. I think comments should be used sparingly to describe things that are not obvious from the code (like why you are trimming 7 characters from the input stream from that 3rd party service).
Thumbs up for the others on the list 👍
|
|
|
|
|
Matt.L wrote: why
Right there is the reason Sander is wrong, we all know how to trim strings but why you need to is the relevant point. Sure sometimes, even most times it is obvious but when it is not then put in a bloody comment for Ghu's sake!
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
First off Sander you don't know how I program nor the other techniques that I use.
Was trying to help others understand that without documentation even great code can be hard to follow.
You learn by having others to help you test your products as well as quality assurance testing by qualified people.
I don't buy your misconception about what was posted as a general guide to help reduce software defects.
Does your software have NO issues at all? I think not.
You obviously haven't read my documentation and comments in my own code... otherwise your opinion might change to realize that you don't have all the answers.
You probably don't have over 39 years of software development on multiple platforms from mainframes to minicomputers in multiple computer languages.
So I take your comments with a grain of salt... we all have a lot to learn and hopefully every day we all get better at the craft of writing software.
We all have unique experiences in the field of software engineering. It is an ever changing environment with new things coming out every day... so none of us knows it all.
Think before you start posting here with your limited experience.
I'm sure that you know a lot... but to best understand things you have to keep an open mind.
|
|
|
|
|
First off, Destiny777, it took you almost a year to reply!? 
Second, my comment was in no way a personal attack, but it seems that's how you're taking it.
From there on your post is just a giant ad hominem, attacking me as a person rather than my argument.
I suggest you read Clean Code by Robert C. Martin, an author with more knowledge and experience than us mere mortals can ever hope to accumulate in this life, and he is against comments. By your own logic you are now in the wrong.
You say "Think before you start posting here [because something that has nothing to do with anything]" and I suggest you do the same (and I guess a year wasn't enough).
|
|
|
|
|
I didn't take your comments as a personal attack at all.
You discounted the thought of even documenting code from what I could tell.
You code your way, I'll code mine.
Successful programming as a team REQUIRES documentation.
Sorry that you took it as a personal attack by me.
Good coding techniques and excellent documentation IS helpful.
|
|
|
|
|
Sorry for that, your (invalid) argument about my experience hit a sore spot.
I've worked for some a-hole who thought he was somehow a better programmer because he had more years of experience [read: years worked as a programmer].
He was sure to SCREAM at me that something as absurd as "design patterns" would never work and he could know because he had 8 years of experience and I was only just getting started.
According to him not even Microsoft used design patterns.
You can imagine that wasn't our first and neither our last argument about code and every time he'd be sure to say he was right BECAUSE he has more years or experience (and he was also my boss).
Experience says nothing about skill or knowledge.
Please remember that
So, peaceful this time 
I agree that good documentation can be helpful.
Unfortunately, documenting is often even harder than writing the code in the first place.
Updating documentation is something I've only heard of in fairy tales.
I've had plenty of experience with documentation and especially code comments, and 99% of the documentation was useless at best.
A useless comment (I've come across this exact comment countless of times!):
int i = 42; Another "duh" comment:
customer.Save(); And this is why commenting just doesn't work:
product.Save(); These are real world examples and most of the comments I've seen.
Anyway, good code (usually) requires no comments.
And, as said, in his book, Clean Code, Robert Martin, an authority on programming, also argues against comments (the entire book is really worth a read!).
That said, documentation is helpful!
When I'm about to use some third party library and I can't find any documentation it's exit library!
So if that was what you meant I'm completely with you.
I've documented my own arrgh.js[^] like that (although you won't find a single // code comment in the source)
So let's either agree to disagree or something in between (docs yes, comments no, agree 50%?) 
|
|
|
|
|
how about
a published style guide (suitable for your organisation) .. that would cover the points you allude to
an automated build process
automated testing
addendum to point '5' of yours .. dont ever let me see you catch an exception and absorb it out of laziness !
|
|
|
|
|
Wasnt there the "10 commandments"?
So dont knowing the last 3 commandments I'll write buggy code forever
PS: these coding rules are common sense also in the Apple universe...
Press F1 for help or google it.
Greetings from Germany
|
|
|
|
|
Let them switch job. Let them code, you be the observer. See how the table turned. They will stop discussing when their simple "Hello World" code got dozen of bug/defect.
|
|
|
|
|
If your project is done slowly maybe and again there alway have a lot of unexpected  . If want fast than lot messy code and mistake because of quick fix
|
|
|
|
|
|
Bernhard Hiller wrote: Half of the people who participated aren't interested in quality (or insist that CI is crap which won't help them)
How do you figure that? Do you think that everyone using CI puts out quality code? Do you think that everyone that isn't in a CI environment doesn't?
Were we all writing garbage before the Good Lord Jenkins opened our sinful eyes to the ONE TRUE WAY?
|
|
|
|
|
Stop shortcutting the SDLC process.
Stop outsourcing your development work.
Show some loyalty to your employees.
Among other things.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
Define "software defect"
Marc
|
|
|
|
|
1. Hire competent engineers
2. Hire competent testers
I'm continually surprised how often companies ignore both of these, especially #2.
Oh, and:
3. Don't think you can write software on a tight, fixed schedule (i.e. two week sprints.) Especially without staggered sprints for testers.
This is the fatal flaw in agile/scrum. Sprints assume ALL work will be done, which means that your deverlopers will be working the first week and testers the second or you simply won't have adequate testing. In a similar vein, I'd add:
4. Factor "sh*t happens" into your development schedule.
|
|
|
|
|
AFR: Aug. 22 "Steve Wozniak says Apple must fix iPhone 7 Bluetooth or revive its headphone jack" [^]
«There is a spectrum, from "clearly desirable behaviour," to "possibly dodgy behavior that still makes some sense," to "clearly undesirable behavior." We try to make the latter into warnings or, better, errors. But stuff that is in the middle category you don’t want to restrict unless there is a clear way to work around it.» Eric Lippert, May 14, 2008
|
|
|
|
|
Or just switch to an Android phone like everyone else.
|
|
|
|
|
Except he also says that he really likes how Android phones are switching to USB-C for audio.
Some confusion, backtracking or bad reporting.
The argument shouldn't be for or against ditching the audio jack. It should go. It should have gone years ago. The argument is about using a lightning port (Apple) or USB-C (the rest of the entire world). If Apple switch to USB-C (and ditch lightning altogether) then I'm happy. If Apple go their own way then they'll lose customers. Lots of customers.Bluetooth headphones just aren't convenient enough.
The other huge, huge issue is that I often need to charge my phone while using headphones (eg long conference calls). With only a single port I either need to buy a splitter or do without.
Steve Jobs may have been able to convince us all this was The Right Thing. Tim Cook and Johnny can't. There's no fire in their bellies, no conviction. It's all about them, frankly, and not about the user.
cheers
Chris Maunder
|
|
|
|
|
Chris Maunder wrote: There's no fire in their bellies, no conviction. It's all about them, frankly, and not about the user.
That's the perfect explanation and is completely explained in this fantastic TED talk by Simon Sinek:
Simon Sinek: How great leaders inspire action | TED Talk | TED.com[^] 
Real leaders focus on the "why". Great stuff. If you've never watched you should. It explains a lot.
|
|
|
|
|
Yes - I use that TED talk constantly when talking to marketing departments of companies looking to advertise with us.
Have some passion, but more importantly, tell us why you do what you do instead of telling us what you have. It makes a huge difference.
cheers
Chris Maunder
|
|
|
|
|
Chris Maunder wrote: Yes - I use that TED talk constantly
The fact that you know about the video and use the information in it is further validation of why you are a great leader of the fantastic CP Community.
|
|
|
|
|
Chris Maunder wrote: Steve Jobs may have been able to convince us all this was The Right Thing. Tim Cook and Johnny can't. There's no fire in their bellies, no conviction. It's all about them, frankly, and not about the user.
Having been part of the "Cult of Mac" for a number of (enjoyable) years, and having been to the NeXT roll-out at the Opera Center in SF, been to the NeXT training camp, and sat at the same dinner table with Steve Jobs, then, later, at Emerald City and Adobe, having interacted with folks from NeXt ... having seen Steve J. in action at BMUG meetings (Berkeley), and Apple WWDC days ... having watched certain skeletons being buried as those behind the scenes were driven ...
I would say that the fire in Steve J.'s belly was quite a cold flame, and one that burned with the narcissistic and megalomaniac conviction of a tyrant and dictator, so often untempered by compassion.
Concern for the customer/consumer ? That is something I would never associate with Apple. Concern with getting as much of the customer/consumer's money as possible in an endless cycle of updates; that's something I'll always associate with Apple (as well any other large-scale enterprise).
I do believe that Steve J. was a great marketer, a genius opportunist, a clever borrower (at best), or thief (at worst), and packager, of other people's ideas, and a master of using his hypnotic charisma to get people to nearly work themselves to death for his approval, or believe they needed things they didn't really need (the "insanely great" syndrome).
Yes, he was also a risk-taker, and an innovator. And, perhaps, it does take a certain kind of auteur style of technology management to really innovate.
I am thankful I never worked directly for Apple.
I appreciate the Mac hardware and UI, but have no desire to own any of it; it's too pricey for me, and I abhor their policy of forcing you to buy various cables and peripherals that you really need to get work done from the git go.
cheers, Bill
p.s. if Xerox PARC had listened to Adele Goldberg's (SmallTalk, later Parc Place) warnings, Steve J. and the other boys from Apple would never have been shown the Star and Alto work-stations, the prototype of ethernet, bit-mapped screen displays with icons, the mouse, laser printers using a Page Description Language, etc. And, we would be, perhaps, in a different universe, technologically.
«There is a spectrum, from "clearly desirable behaviour," to "possibly dodgy behavior that still makes some sense," to "clearly undesirable behavior." We try to make the latter into warnings or, better, errors. But stuff that is in the middle category you don’t want to restrict unless there is a clear way to work around it.» Eric Lippert, May 14, 2008
|
|
|
|
|
You can never beat first hand accounts.
Wow. Thanks Bill.
cheers
Chris Maunder
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
