Just as the title says: can I force LibreOffice basic to report an error for undefined variables? I am so used to sane languages that I keep blundering into this: when I misspell a variable, LibreOffice just creates it with an initial value.
Ideally I would like to force this in one place for all macros I use in documents I create. If that is not possible, what is the most reliable and least onerous way to force it?
I have realised the basic answer is quite straightforward – one might say Check the Fing Manual – and I provide it below – but this has caused me enough grief that it seems worth documenting here
Yes, you can do this per module:
Add Option Explicit at the start of every module you write. For details, see the LibreOffice help under Macros and Programming – Using Variables – Forcing Variable Declarations (link for version 6.1).
I think that: no, you cannot do it for all your documents and modules in one place:(
Related
I have a few related questions about pragmas. What got me started on this line of questions was trying to determine whether it's possible to disable some warnings without going all the way to no worries (I'd still like to worry, at least a little bit!). And I'm still interested in the answer to that specific question.
But thinking about that issue made me realize that I don't really understand how pragmas work. It's clear that at least some pragmas take arguments (e.g., use isms<Perl5>). But they don't seem to be functions. Where do they fit into the overall MOP? Are they sort of like Traits? Or packages? Is there any way to introspect over them? See what pragmas are currently in effect?
Are pragmas built into the language, or are they something that users can add? When writing a library, I'd love to have some errors/warnings that users can optionally disable with a pragma – is that possible, or are they restricted to use in the compiler? If I can create my pragmas, is there a practical difference between setting something with a pragma versus with a dynamic variable, aside from the cleaner look of a pragma? For that matter, how do we decide what language features should be set with a pragma versus a variable (e.g., why is $*TOLERANCE not a pragma)?
Basically, I'd be interested in any info about pragmas that you could offer or point me towards – though my specific question is still whether I can selectively turn off certain warnings.
Currently, pragmas are hard-coded in the handling of the use statement. They usually either set some flag in a hash that is associated with the lexical scope of the moment, or change the setting of a dynamic variable in the grammar.
Since use is a compile time construct, you can only use compile time constructs to get at them (currently) (so you'd need BEGIN if it is not part of a use).
I have been in favour of decoupling use from pragma's in the past, as I see them as mostly a holdover from the Perl roots of Raku.
All of this will be changed in the RakuAST branch. I'm not sure what Jonathan Worthington has in mind regarding pragmas in the RakuAST context. For one thing, I think we should be able to "export" a pragma to the scope of a use statement.
In the autoconf manual, it is noted that
AC_INIT (package, version, [bug-report], [tarname], [url])
defines multiple macro names such as AC_PACKAGE_NAME and PACKAGE_NAME.
Running configure also generates a config file with definition like the following:
define HAVE_LIBGMP 1
As I am writing C++ code, I find these macros annoying yet useful. In fact, it happened many times that I needed to link with a library that uses the autotools and thus has these macros in its headers. So the situation is that there is conflict on headers macros such as:
define PACKAGE_NAME "library"
define PACKAGE_NAME "mine"
So, I was wondering if there was a way to tell the autotools to define at least some of these macros inside some kind of structure as follows:
`struct header_information{
static string package_name;
static bug_report;
....
}`
and then initialize it with the right macro names.
This solution would keep these informations encapsulated and does not pollute the global namespace ?
It seems to me like you want to abuse a package-private, build-system-ony configuration header file (config.h) that just so happens to define a convenient macro name that you'd like to use. I think the pretty obvious answer is "don't do that", or else you're on your own.
Unless I'm misunderstanding you?
Those defines are there so that the particular library can use them. It's not meant for other things to include. In fact, the majority of the things in config.h are completely useless outside of the particular package.
That doesn't mean that the library that config.h file belongs to couldn't provide what you're looking for, by defining a public struct in a header that uses those variables. Or perhaps a library that uses pkg-config (if you're just looking for package names) can provide some of information for you. But I don't think that autotools would or should provide that information to you.
I was looking through someone's code one day and I was annoyed how they declared all their functions first and then later called them below. I guess I'm use to Visual Studio's automatically generated functions, that are made after you call them- and I was wondering, which way do you prefer? Or is there a standard on these kind of things?
I'm not sure what you mean by this. In C and C++, a function must be declared before it is called, otherwise the compiler won't know how to verify your arguments and return values.
I don't think it matters as the functions are all loaded into memory before execution begins. It's mostly a matter of style.
Personally I put miscellaneous functions that aren't part of a class definitions at the bottom of my code so it's easier to read.
That's just my $0.02 though.
Whatever Visual Studio do automatically can be considered a Microsoft standard. Not always the best standard, but a standard anyway =)
I'm making some significant changes to some VBA code, and some variables are being deleted and/or renamed. It would be a lot easier to find all the locations I need to update if the compiler would complain to me that the variables don't exist instead of creating it on the fly.
How do I force VBA/Access to require variables to be declared?
You need to use Option Explicit at the top of each VBA code module including forms and reports.
You can set this for all future created modules and VBA code behind forms and reports by going into the VBA editor >> Tools >> Options >> Editor tab and ensuring Require Variable Declaration is checked.
From Access 2003 help:
Require Variable Declaration — Determines whether explicit variable declarations are required in modules. Selecting this adds the Option Explicit statement to general declarations in any new module.
I also use camel case when I Dim my variables. ThisIsAnExampleOfCamelCase. As soon as I exit the VBA code line if Access doesn't change the lower case variable to camel case then I know I've got a typo.
Some History on OPTION EXPLICIT and Access VBA
To follow on from Tony's answer, here's some explanation of why there are issues with OPTION EXPLICIT not being on in some Access code modules.
In Access 95 and Access 97 (the first two Office versions with VBA), Access had a different code editor than the other office programs. In Access 2000, Microsoft implemented the VBE from the other Office apps in Access. At the same time, MS chose to make Access VBA modules behave like the modules in the other apps, which defaulted to not having OPTION EXPLICIT.
Thus, in Access 2000, by default, modules were created without OPTION EXPLICIT.
This was, of course, a really stupid design decision on MS's part, and they reversed it later (I can't remember if it was Access 2002 or 2003 that rectified the problem and defaulted to OPTION EXPLICIT in all new modules again). The reason it was dumb (and MS should have known this) is because Access is a DATABASE APPLICATION DEVELOPMENT tool, and thus is operating on data that is strongly typed. Thus, the code environment should be strongly typed by default so that it is in harmony with the data it is working with.
In Excel or Word, the data is not strongly typed, and it thus makes more sense to use variant data types for just about everything, simply to make it easier for everyone. The downside of implementing that by not using OPTION EXPLICIT is that you can end up with typos that automatically intrdoduce new variables [such as the variable "intrdoduce" -- if I was writing this post with OPTION EXPLICIT, that wouldn't have happened without producing a runtime error! :)]. This is a problem with all such languages that work this way (I pull my hair out working in PHP, where variable names can be distinct by case, i.e., $Var is not the same variable as $var; but I digress), but MS made the decision to implement it that way in Word and Excel on the theory that the people writing code there are going to have an easier time of it if they aren't forced to declare their variables.
So, MS made the mistake of making Access's version of the VBE like the other apps, even though there was no logic internal to Access's own purposes that supported that move. And MS then backed out that change and returned to the previous status quo (i.e., OPTION EXPLICIT by default in all modules).
Thus, you will often see apps that began life in Access 2000 that have modules all over the place without OPTION EXPLICIT. When I have to work on such an app, my first task is to implement OPTION EXPLICIT in all modules and then fix the damned thing so it will compile (which is often quite tough, given that the thing was programmed without it).
This question was quite helpful for Excel, you might see if it'll work for Access:
Lost Variables
Essentialy, MZ-Tools will search through your code and tell you what is not being used. The version for VBA can be found here. Use the Review Source Code feature.
What language(s) have comments with side effects? In essence, comments which are not comments....
English. Do I win?
DOS Batch Shell programming
The REM (Remark) allows you to put in a comment. But it has the side-effect of modifying the ERRORLEVEL variable to 0.
In a sense, it makes last operation a success.
I don't know how a comment can fail, but if it does, you are covered.
I can think of several places where comments aren't really comments.
HTML and script tags (providing support for browsers that don't allow or support scripts).
And then, considerably more obscurely:
IBM Informix 4GL (I4GL) and 4J's Genero (successor to Informix Dynamic 4GL, D4GL). The notation '--#' was used by D4GL to include material only applicable to D4GL; I4GL would see that as a comment. The inverse notation was '--#', which looked like a comment to D4GL but was treated as active material by I4GL.
And, even more obscurely:
I wrote an I4GL file which was dual-languaged, exploiting I4GL's multiple comment facilities. Material starting '#' (hash) marked the start of a comment outside of strings - up to the next newline, as does '--' (double-dash). Also, '{...}' (braces) enclose multiline comments.
The top of the source file was actually a shell script, mostly enclosed in '{...}' which is, of course, perfectly legitimate in shell. The shell script was a data-driven code generator that copied itself to the top of the output, and then generated about 100 functions which were all depressingly similar but slightly different (in a language without templates or a pre-processor). The code had to validate what was in the database for a given ship against incoming data from an external source (Lloyds of London, in fact), to see what had changed since the last time the external data was received. Non-trivial comparison work, especially since it had to deal with database (SQL) nulls.
The file was not really a Quine program, but it had some points in common with it. In particular, you could feed the script broken I4GL code and the regenerated file would be perfect again, basically because it ignored the existing I4GL code.
Haskell can turn the usual comments in code paradigm upside down by having code in comments - also Mathematica and the like; literal programming is a nice feature for the more mathematically inclined languages.
I also find annotations in Java are like comments with behaviour.
Then of course there are "polyglots" -- programs which can be compiled/executed in multiple languages. Usually these rely on the fact that the same line is a comment in one language, but an actual line of code in another.
QBasic has a use of comments all its own: REM $STATIC or REM $DYNAMIC set how arrays are allocated.
Another example: When web browsers parse comments <!-- -- -->in<!-- -- -->correctly.
CSS for clever cross-browser hacks. Of course, I wouldn't really call CSS a language.
Just stumbled upon this old question and my first thought was javadoc comments.