I have a new found respect for programmers...

[mjr]

And for St Vidicon's sake, USE CONSTANTS!

(== is 'is assigned to', ; is 'end of statement', and // is 'everything after this and on the same line is a comment for humans not the computer')

Close... at least in most C-based languages (C, C++, C#, Java). I think you have it backward.

The "==" actually is "equality" (i.e. 5 == 5), whereas the single = is the "is assigned to", as in "a = 5" (assign the value of 5 to a).

To that end, there are a lot of places and people in the industry that frown on "magic numbers". A constant like that, at least these days, would likely be called a "magic number". Though you could work around it by setting up an enum. So that might look like:

enum HitFailureChance{
Low = 33,
Medium = 66,
High = 90
}

And then in your constant, you could do the following:

private const HIT_FAILURE_PERCENT = HitFailureChance.Low;

Or, you could do as some suggest today, and work with an XML-based config file, and pull the percentages from that. This way, if you want to change the percentages, you can change them in an XML file, and not have to worry (for the most part) about re-compiling your application.

But get this...JavaScript has a "triple equals" (or ===) It does not check for equality based on type coercion.

Sometimes in Javascript, you can get away with things like:

if (5 == "5")

which would return true (I believe).

However, if you did something like the following:

if (5 === "5")

you wouldn't get the type coercion, and the result would be false.

Because 5 the number is different from 5 the character, and since they are different types, they're not equal.

[prjkt]

well most of this thread has gone way over my head... argh.

On the other hand I have figured out a way to script a button in my app that'll generate a formatted PDF based on the info provided and automatically attach it to an email with the client's email address already entered ready to go. I have high hopes that I can actually finish* this project before I go back to work.

*Most likely, there'll be some other feature I'll want to add afterwards

[sms001]

and to break it down into smaller chunks that can be solved and then strung together

Flowcharts are your friend.

It really does take a certain mindset/way of thinking that some people can do well,

That's why I moved into other areas of computer support. I can program, and I do it well. But it was always work, I just don't have that innate talent for it. It's like a sport or music; lots of practice will get you pretty far, (and can even be fun) but some just don't have the knack for making those professional levels easily.

Good luck and have fun prjkt. I'm sure you'll be pleased with your final results since you tailored them to your own specs.

Semi-relevant XKCD:

[prjkt]

Haha be seen that before, and believe it or not, was actually part of my decision process in building this program. The invoicing side of things takes about as much time as doing it manually, but (hopefully) takes away all the errors - as I'd usually do my invoicing late at night when I have finished processing/submitting the photos, I'd occasionally stuff up dates, or forget to change the invoice number leading to not getting paid for that shoot until I figured out (but manually entering all my invoice details into a spreadsheet and working out what had been paid, and what hadn't)

This second part would take quite a while to do, and once finished will only be a button press away, plus end of financial year will be much, much quicker and accurate. Which has been my goal all along

[Racket_Man]

Well, my understanding is in certain CompSci programming courses, they actually do want you to comment your code. This is so you can follow along with yourself, and illustrate to the instructor you have a general idea of what's going on and can somewhat communicate it.

However, in the "real world" it's different. A lot of places do not want you to comment your code. They will sometimes allow for the XML-style (or JavaDoc) type comments above the method or class, but NOT within the methods themselves.

Unfortuneately if you have had to deal with spaggetti/uncommented code like I had to years ago, the real world will really bite you in ass big time.

I worked for a family jewelry company years ago. MANY moons before I started they had an inhouse programmer build them a sales/inventory tracking/reporting/accounting system. When I started there, said programmer was LONG gone and all I had was bunches and tangles of RPG code, nonuseful variable names (like A S C D), undocumented switches, and code that would jump all over the place. Trying to make sense of JUST ONE of the main tracking programs took me 6 full months and I doubled the size of the source code by adding comments and explanations to all of the garbage I found in ONE program.

I lost a LOT of hair over that system. AND from what I saw on other jobs was that this was fairly typical even though most programming course work even back in the late 1970's (during my first stint in college) beat flowcharting and in/out of program extensive documentation into our heads.

One of my programming Professors had a "flowchart" on his ceiling that did look like a bowl of spaggetti.

[wolfie]

Just be sure to remember that the first 80% of a programming project consumes 90% of the available programmer time. So does the last 20%.

[dalesys]

Just be sure to remember that the first 80% of a programming project consumes 90% of the available programmer time. So does the last 20%.

Not quite.
The first 90% consumes 90% of the resources allocated.
So does the next 9%...
And the next 0.9%...

There is no exit in this DO...UNTIL

[Seshat]

Sorry, you're right (re single = vs double =).


I can't imagine totally commentless code being fully readable. Sooner or later, you'll come across a place where simply having well-named variables and functions is enough.
Maybe it does happen, but I just can't imagine it.

[Jetfire]

Thankfully, my company doesn't have any idiotic policies like "Self documenting code". We say the code must be clear, but it should also be documented. Some of our devs don't put much comments in, but most of us do.

I find when writing/designing a task, it's helpful to pseuducode it first, to hit the main things I need to do first. And then to code each pseudocode section, but leave the pseudocode in place as the comments.

So if I have a function to gather information from multiple sources, do some calculations and create a PDF out of it, I would start with something pseudocoded like this:

PDFObject gatherInfoAndCreatePDF()
{
//Get data from User DB
//Get data from Purchases DB
//Get current Date/Time
//Calculate summaries of purchases.
//Create (and return) the PDF

}

And from that, I just need to do what those 4 steps do, and I can leave the comments in place to give general comments on what's going on. And if you need to update this later on (say you have to add a new data source to get pricing information from for example) the comments will give you an idea of where that new part should go.

[mjr]

Thankfully, my company doesn't have any idiotic policies like "Self documenting code".

I think the thought process behind it is that if you document through comments, that over time the comments become "stale".

In other words, if I write a comment that reads:

// This checks for X functionality by doing A, B, and C.

Then later, that functionality gets modified, but the comment doesn't, the comment is now "stale".

Which is why some places don't like comments, but instead want methods named things like:

AddTwoIntegers(int num1, int num2)

or variables named things like recordCount, isOpenConnection, and so forth. They give you an idea of what the variable may be (recordCount is likely an int, isOpenConnection is a bool).

[Jetfire]

There is that. But if the company has a proper review process, then the reviewer should be looking for updated comments too.

And if the comments are near the action, they should be obvious for updating.

It doesn't always work out, but even stale comments can be better than none; at least you'd have ideas of what the intent was as a starting point.

Self commenting code can go stale too. If the class purpose changes but the variables aren't updated because the original behavior is mostly intact (or is just a pass through) then things can get just as confusing.

Reality is, there isn't really a good solution one way or another. As long as you are consistant then it can be ok; but eventually if the code is live and being maintained, things will drift no matter what.