Help with 'ERROR : Name not defined within scope

[Profaitchikenz Haiku]

12 minutes ago, Wulfie Reanimator said:

Code is documentation.

I agree 100%. Descriptive names, formulae written to correspond as closely as possible to the design documents,  and brief commenting where something might be a little obscure, there are worth twice their volume in comments.

[Rolig Loon]

2 hours ago, Profaitchikenz Haiku said:

I agree 100%. Descriptive names, formulae written to correspond as closely as possible to the design documents,  and brief commenting where something might be a little obscure, there are worth twice their volume in comments.

The unspoken assumption, of course, is that all people who will be likely to look at the script later have the same level of scripting expertise.  I do not need to leave many detailed comments in a script that will only been seen by fairly sophisticated scripters.  They will be able to read my code and understand it without verbose comments.  If I am writing a script for a client who may need to make his own small modifications later, but is only moderately skilled, he'll need more guidance.  So I'll add more notes.  I'll also add more notes if it's likely that a talented scripter -- even me -- will look at a complicated script a year later and ask something like, "What other routine is changing this global variable to trigger what's happening at this spot?"  Flow of execution can be really hard to follow without good notes.

[Anna Salyx]

On 4/6/2021 at 10:40 AM, Madelaine McMasters said:

The VP of engineering at my company was weirdly proud of writing undocumented code.

4 hours ago, Wulfie Reanimator said:

The "comments are bad" thing comes from a valid place, but that guy seems to have taken it to an extreme.

This tagged a memory I'd forgotten all about -- a list from sometime in the late 80's that grew out of the tongue-in-cheek satire about how real men don't eat quiche.  Someone, or several someones contributed to a list of the characteristics of 'real programmers' and what they do and don't do.  It's own tongue-in-cheek spotlight on some of the toxic attitudes in programming circles.  One of the lines seems to have be come the mantra of the person in question: 

     Real programmers don't comment their code. If it was hard to write, it should be hard to understand and harder to modify.

--

and fwiw I'm in the camp of common sense commenting.  I don't comment every line but if the routine is not really obvious I'll at least comment what the intent of a function or procedure block is with clear variable and constant names.  Anyways, don't have much more to add, just wanted to insert a touch of old old satiric humor.

 

Edited April 7, 2021 by Anna Salyx
fix typo

[Madelaine McMasters]

9 hours ago, Wulfie Reanimator said:

When the code is so unclear that you need to write more to explain what it does or how it's done, you create two problems.

All of the code I wrote during my career was real-time, most of it in assembler, a lot of it signal processing, and some of it just plain weird (self-generating/modifing code). More than once, I wrote little kernels of nearly impenetrable code, perhaps 20 lines long, prefaced by pages of comments. Even with my grand commentary, some people had to walk around the block a few times before they had their "aha" moment. I was one of them, when I returned to a project I'd done years earlier and couldn't understand what I'd done. Without the comments I'd never have figured it out.

Sometimes you just gotta do things this way to get the performance you need, and copious comments help.

[Mollymews]

6 hours ago, Madelaine McMasters said:

All of the code I wrote during my career was real-time, most of it in assembler, a lot of it signal processing, and some of it just plain weird (self-generating/modifing code). More than once, I wrote little kernels of nearly impenetrable code, perhaps 20 lines long, prefaced by pages of comments. Even with my grand commentary, some people had to walk around the block a few times before they had their "aha" moment. I was one of them, when I returned to a project I'd done years earlier and couldn't understand what I'd done. Without the comments I'd never have figured it out.

Sometimes you just gotta do things this way to get the performance you need, and copious comments help.

i like browsing thru old school machine language code. Without the comments for each instruction then I would be lost trying to work out what is happening

like the examples on this page: https://www.c64-wiki.com/wiki/Assembler_Example

i think that was the thing back in the day.  Industry standard source code was pretty much always written and documented for the next person, not for the author. The author knowing that the next person following them into the chair, may have zero actual experience in the particular language, even if a competent programmer of other languages

for sure a machine language programmer knows how to disassemble a code block and work out from the opcodes what is happening, but is a tedious business to do it this way

edit add: Is like you and others have said. It depends on who the intended audience is

Edited April 8, 2021 by Mollymews