Indenting and Spacing Revisited.

[The_Doc_Man]

I have always problems with the way sql-strings are constructed. You have to read the whole line and find if it contains the necessary space and ampersand.
Why not place them at the beginning of the line? In one glance you can see if all is correct:

active_sql = "SELECT Gebeurtenis_tbl.Gebeurtenis_id FROM ((Gebeurtenis_tbl" _
& " INNER JOIN Status_tbl ON Status_tbl.Status_id = Gebeurtenis_tbl.Status_id)" _
& " INNER JOIN Deelnemer_tbl ON Deelnemer_tbl.Gebeurtenis_id = Gebeurtenis_tbl.Gebeurtenis_id)" _
& " WHERE Relatie = TRUE" _
& " AND Persoon_id = " & HB_id



Imb.

Your method is equally as valid as any other method since the underscore (continuation) and ampersand (concatenation) are considered as independent operators. They can appear in either order, so... whatever floats your boat.

 

[Isaac]

In general, I like to separate the ideas within code, so these are a few considerations:
If the variable won't be used yet, I don't want to deal with it.
If I change the code later and I don't need that variable anymore, I don't want to check whether the variable is orphaned some other place.
If I will refactor the code, I want to copy paste more easily, instead of copying one block from here and another from there.
I don't like to declare variables inside a loop, so I put them outside for the loop to reassign them and make them literal variable things, but because there might be a few, I declare them in order of appearance.

There may be other considerations I'm missing.

Those are good reasons. Thank you for explaining. It makes me rethink a little bit my habit of putting them all at the top. I like to name them something very informative so it's easier to understand down below, but I have to admit that it would be even easier to understand down below if it were also declared down below. Will have to think about this one some more, thanks!

 

[Edgar_]

Those are good reasons. Thank you for explaining. It makes me rethink a little bit my habit of putting them all at the top. I like to name them something very informative so it's easier to understand down below, but I have to admit that it would be even easier to understand down below if it were also declared down below. Will have to think about this one some more, thanks!

Thanks for the appreciation. I hope that contributes to a better development experience for you and others.

 

[The_Doc_Man]

If I may offer an opinion, deferring the DIM of a variable doesn't appeal to me because doing that means I don't know exactly when that variable is defined in my code. Oh, I know it exists from the beginning of the module or routine in which it is instantiated even if the DIM was in the middle. But by having all the definitions together I don't have to look so hard for them. And I often have over 50 variables in my Genealogy database forms. Particularly since I have several issues to manage in each routine.

 

[AHeyne]

@Edgar_ : Your coding style is very close to mine, I like it!

But one question/hope I have: Your comments are just explanatory in you post here, or?

Because in my eyes, comments should (mostly) only tell the reader of the code the "why" and not the "what" or "how".

 

[Imb]

Your method is equally as valid as any other method since the underscore (continuation) and ampersand (concatenation) are considered as independent operators. They can appear in either order, so... whatever floats your boat.

Well yes, everyone his own flavour!

I like the flavour that "unhides" the pitfalls, so it is easier to "see" the problem.

Underscore and ampersand are not so interesting. For me it is the prominent space on the beginning of the line.


Imb.

 

[Edgar_]

@Edgar_ : Your coding style is very close to mine, I like it!

But one question/hope I have: Your comments are just explanatory in you post here, or?

Because in my eyes, comments should (mostly) only tell the reader of the code the "why" and not the "what" or "how".

I agree with that, since "what" and "how" is the code itself.

I think I spend a shameful amount of time naming things just to avoid dealing with the addition of comments. They make the code much longer than it should be (I hate long code), but if someone else has to read it, I might add a few comments here and there just in case.

Now that I recall, a good amount of the comments I write are along the lines of: "if you don't do this part, this sh*t will break". The curse words are necessary for context. I might also add a few comments as "titles" before blocks of code at times where I believe it makes sense, specially in some classes.

 

[AHeyne]

I think I spend a shameful amount of time naming things just to avoid dealing with the addition of comments. They make the code much longer than it should be (I hate long code), but if someone else has to read it, I might add a few comments here and there just in case.

I know that only too well. Finding good names is not easy and lines become (slightly) longer as a result, but I like code that reads like a book.

Regarding the additional comments you mentioned, which you like to add from time to time:
There is a risk that these become obsolete when the code changes. This is unlikely to happen with well-named procedures, unless you are careless when changing procedure code.

 

[AHeyne]

Hmmm, but you just explained yourself that this is a WHY comment after all:

Sometimes WHAT is necessary because a programmer looking at the code would question why you are doing something that way.

You then seem to explain why you have implemented something the way you did.

 

[The_Doc_Man]

Now that I recall, a good amount of the comments I write are along the lines of: "if you don't do this part, this sh*t will break". The curse words are necessary for context.

I remember looking at the network code for Digital Equipment Corp's TOPS-10 operating system (on the DEC KA-10 CPU) and somewhere in there was "Dave Cutler swears this will work." I can't tell you what it did because it was 50 years ago that I saw it, but it was a pretty innocuous instruction in the PDP-10 Assembly language.

 

[Edgar_]

There is a risk that these become obsolete when the code changes. This is unlikely to happen with well-named procedures, unless you are careless when changing procedure code.

Absolutely, comments are an extra thing to maintain and I despise them because of that and their huge size

I remember looking at the network code for Digital Equipment Corp's TOPS-10 operating system (on the DEC KA-10 CPU) and somewhere in there was "Dave Cutler swears this will work." I can't tell you what it did because it was 50 years ago that I saw it, but it was a pretty innocuous instruction in the PDP-10 Assembly language.

The entire Access community seems to trust similar blessings as far as my experience goes, it's why I tend to look at the debugger more than it is adviced too.

 

[The_Doc_Man]

Absolutely, comments are an extra thing to maintain and I despise them because of that and their huge size

On the other hand, if you are pressed for time and can't maintain a separate journal, at least the comments are right there for you to give yourself hints as to what you were trying to do. You don't even have to open a new file to record your intentions.

 

[DickyP]

Do what you want with personal databases - comment/don't comment. However, if you are even pretending to do things professionally then updating the documentation (comments, journals, release documentation) is something you'd WANT to do as part of the release process!

 

[Isaac]

I don't think comments that explain How are necessarily all bad, if the code is quite complex, your comment might save someone an hour of figuring it out themself, it's not necessarily all bad.

I agree about naming variables - I always say, choosing a variable or sql alias name is NOT, NOT an invitation to use something very short and cryptic.
It's an opportunity to be DESCRIPTIVE. I cannot stand it when people code in sql select from table1 a, table 2 b, table 3 c.
Your eyes have to dance around trying to remember what a b and c are like you're going crazy..

Thank God SSMS has bracket matching and other-things-matching, which I have my color set to a bright green to see what an alias is for, but sheesh, some code just tries to make it difficult.

 

[plog]

I cannot stand it when people code in sql select from table1 a, table 2 b, table 3 c.Your eyes have to dance around trying to remember what a b and c are like you're going crazy..

Ugh, you're triggering me and by that I completely agree and then some.

When I see aliases in the FROM I know I am dealing with someone who's main objective isn't to write good SQL but to convince other people they know how to write good SQL. Like 90% of the tattoos in the world are on people who want to be a person seen as someone who has tattoos.

 

[The_Doc_Man]

Like 90% of the tattoos in the world are on people who want to be a person seen as someone who has tattoos.

Yes, but most of the neighborhoods in New Orleans where you FIND those tattoos have the dignity to at least spell them correctly.

 

[The_Doc_Man]

When I see aliases in the FROM I know I am dealing with someone who's main objective isn't to write good SQL but to convince other people they know how to write good SQL.

Except for folks like me who don't give a rat's patootie about whether it is perfect SQL, but who DO need aliases when the table names are long enough to have a decent chance of being mis-typed. Not to mention that when a sub-query is involved, those aliases are somewhat required.