|
But you laptop contains a desktop as soon as you login so you actually are lugging around a desktop?
|
|
|
|
|
Carbide is designed more like a Jupyter notebook, allowing for live markup, annotation, and manipulation of code and data "Show, don't tell"?
Because sometimes you need an IDE that I don't understand the purpose of?
Well, I suppose it's good to show people something, like JSFiddle or summut.
|
|
|
|
|
It doesn't check for code vulnerabilities, but for configuration options and security mechanisms Yeah, but what do they know about websites?
|
|
|
|
|
I very sure all torrent WEBSITE for piracy will show have virus  (JOKING)
|
|
|
|
|
As an IT management consultant, probably the most frequent question I hear is some variant of “how can we get our defect count down?” Don't write code?
|
|
|
|
|
As a Software Developer for nearly 39 years, There is NO silver bullet on reducing software defects.
You cannot write bug free software.
However there are ways to greatly reduce software defects.
I have written software on a variety of software platforms in that nearly 39 years. Currently writing software for Windows PCs, so my details below assume that you too are using Windows... However if you are programming for a different Operating System, then adjust my instructions below to accomodate that Operating System.
Here's what I suggest:
1. When writing software, make the labels, buttons, etc that you use on Windows Forms or WPF Forms not use the DEFAULT names such as label1 or button1. Change the names to describe how you intend to use those items (objects) in your code behind such as lblErrorMessage or btnSave before you use those objects. That way it helps self document your code.
2. Use variable names that describe what they will be used for instead of using things like x, y, and z. Reading code that uses something like "x = y * z * a" doesn't help you understand what that does... However using "CalculatedInterest = PrincipleAmount * DailyInterestRate * DaysOfInterest" actually helps you understand what is going on.
3. When writing subroutines / functions use descriptive names. Once again this will help self document your program.
4. 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.
5. Test your code over and over and over. Don't forget to use "Try...Catch..." Blocks to prevent your code from crashing unexpectedly. Test valid and invalid data to make sure that your code works like you want it to work.
6. Take time to test your executable code and not just rush it out the door. Have other people help you test your resulting executable code. Then make code fixes as needed and repeat this step as many times as it takes to make sure your code works as expected.
7. If your program needs to have a Software Installer, create the installer and test it on say Windows 7, Windows 8.0, Windows 8.1, and Windows 10. If there are problems with any of those versions of the Operating System, go back and fix your program and / or the software installer.
Hope this helps someone write better software,
Bill G.
|
|
|
|
|
Forgot to add the following:
Make sure that your variable types match what you are doing. In other words, don't use a floating point variable when you intend to use integer values.
For Example, years ago at a previous job, a novice programmer used a floating point variable instead of an integer value. They printed the value of the variable but didn't realize that when converting from floating point values to integer that the fractional part gets truncated (dropped without rounding) ... so when they are looking up data in a string everything was one short of what they intended to get. By simply changing the variable type to integer the "bug" was fixed very quickly.
|
|
|
|
|
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
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
