|
raddevus wrote: That's how jokes are supposed to seem.
Sorry... I failed to see the joke icon and/or the humour. 
In this present crisis, government is not the solution to our problem; government is the problem. ~ Ronald Reagan
|
|
|
|
|
|
"Oh, it was just the cat."
|
|
|
|
|
If there is intelligent life there it is currently receiving reports of the end of World War 1 and is probably deciding to adopt a wait-and-see policy with regard to making contact.
|
|
|
|
|
Duncan Edwards Jones wrote: If there is intelligent life there it is currently receiving reports of the end of World War 1 and is probably deciding to adopt a wait-and-see policy with regard to making contact.
Or, they saw that our world was in turmoil and thought "Now is the time to strike".
|
|
|
|
|
..but due to a miscalculation of scale, their entire invasion fleet was swallowed by a small dog.
|
|
|
|
|
It's the time to strike when we are at peace, fat and lazy. Even your cat knows to wait until the prey is not alert and ready to bite.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
If software development were a circus, we would all be the clowns.
|
|
|
|
|
I'd love this to be a real signal sent from aliens, so that we could later say : well, we first joked about it in the Lounge before it being one of the biggest piece of news in mankind.*
*And yes, it will take at least 190 years for them to send an answer to our signal, so we will not see it happen, but still...
|
|
|
|
|
I suspect we are not capable of sending a signal that distance with enough power to raise it above the background noise!
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
His company is widely credited with making the first commercially successful clamshell laptop, the Compass. Because no one should have to lug around a desktop
|
|
|
|
|
|
|
His battery died?
In Word you can only store 2 bytes. That is why I use Writer.
|
|
|
|
|
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
