Related
As I mentioned before, I am hardly a programmer, so I once again need the expertise of those that are...
I am working on a program that will help me manage some data for a volunteer emergency communications group. In this program I currently have multiple different structures built for multiple different objects (if I am using the term correctly). I have a structure for Site Personnel, a structure for Members (yes they are different), a structure for Operation Info (considered its own object), and a structure for Facility. This was all fine and well, even having each element of the structure defined with <VBFixedString(nameOfConstant)> to ensure an equal record length.
And that is where I hit my problem. Each object (again I hope I'm not butchering this term as I am calling the Facility or the Site Personnel etc the 'object') is a set of fields for a random access file (I abandoned the Excel file idea, way too much headache and nothing but failures on that front, I'll use an in-house system). And, certainly to all of your dismays, I did finally decide to go with FileOpen, FileGet, FilePut, etc for my random access file management (I can already hear your teeth grinding and your skulls crackling to epic facepalms, but believe me I NEED to go simple for this presentation version and for the Version 1 Release which will be beta tested at a National Disaster Medical System exercise in May). The problem I encountered is that each file will need its own filenumber, its own position, and so on, and each one will need a Dim Temp as <structure> where <structure> is SitePersonnel, OpInfo, MemberData, or other relevant structure. Each file will also need its own file handling controls, such as GetRecord, PutRecord, DeleteRecord, NextRecord, PreviousRecord, AddRecord, and so on, and each file will need its own functions for file opening and finding the last record. The reason each structure will need its own copies of this code is that I cannot find a way to pass in a variable to a module-level function such as Public Function FileOpener(ByVal FileNum as Integer, ByVal StructureName as String, ByVal FileName as String, ByVal AccessType as String) and in the code define Dim Temp as (StructureName) where StructureName would be a String value for the actual name of the structure. And finally, I decided to have the redundant file handlers in each object since at any time there can be two or more of these file open, reading, writing, and seeking. Last thing I need during an emergency is for a module-level function to get confused and return the wrong data.
Now that you have the background, this is where I really need some advice. I am aware that structures can have Functions, so I could code each of these functions into the structure. However, I have also started thinking that an object this complex and that can do so many different things may just belong in a class instead of a structure. I am not familiar with classes in Visual
Basic, but I am familiar with Classes from Java, if there is any similarity between the two on the OOP level. So my question is this: Would this example be better (and more reliably) handled in a Structure, or in a Class? And if in a class, would I be best off with each Class in its own file, or should I combine all of these classes into one Module (mainly for clarity and ease of maintenance)?
I apologize again for any permanent damage I have caused anyone here by my sub-newbieness and painful choice of code, and I thank you ahead of time for helping a sorta-noob get back into the swing of things (last Visual Basic program I wrote was when Visual Basic 4 was hot off the press, yep, that long...).
For a system like yours, to manage users and other objects, I recommend the use of classes. They usually get used for management system as they offer the abbility of hierachical variables and functions, so you don't accidentaly call an internal function or access a variable you shouldn't. Also, classes are more flexible than structurs, so you should preferable use them when you aren't sure wether a class or a structure is the better way.
As Plutonix pointed out before, this is not a platform for recommendations, it is for problems with code. So next time, please go to a VB.Net forum. The text written above is my opinion based on my knowledge about the difference between classes and structures and this msdn-article. Further internetresearch is still something you should do, maybe ask in forum or friends / other programmers you know.
I've been applying VBA at work for a number of purposes. I have noted the more 'clicks' a user has to do for a form (with a number of macros), the higher the rate of error. I was wondering rather than having 3 separate functions requiring 3 separate clicks - should I bunch all these functions together into the one sub module for ease of use?
Clinical staff have indicated that this would work best with them, but in terms of code optimization and keeping different functions separate - wouldn't it make things very messy? As I'm still in the process of learning VBA, I thought I'd turn to the expert community which has helped me out a lot so far.
I'd appreciate any and all comments regarding your thoughts on this and how I can create best-practice VBA standards to adhere towards.
An example of this would be the static copy function I have created and the monthly Calculation function. For the monthly calculation to be completed it pulls data from a summary tab and compares this against the static data. However for the static data to first be captured - the user needs to click the static data macro. I've separated the static snap-shot function and the monthly-report function but was wondering if I could instead combine both of these into one function. Readability wise it's not problematic (as I have the comments explaining each section) - but standard wise, would it be unwise?
I apologize if this question is somewhat broad in nature.
After reading around a few forums I've picked up the following information:
Do not use global variables unless you have a specific reason to do so
Don't forget to initialize variables else you may run into sub-script errors
Keep your code simple (iPhone Approach - one click approach)
If modules are similar consider grouping the functions together into one
Macro recorder is your friend
Thanks for the tips everyone!
What is the significance of declaring variables in VB/VBA like so:
Private m_sName As String
Private m_lAge As Long
As opposed to;
Private m_sName As String
Private m_lAge As Long
I am working on a project which up to now uses the latter, and has done since long before I joined the project. Two new developers have joined the team and have begun to use the former. I have seen such pagination previously and wondered; what is its heritage and what advantages/disadvantages does it have? My own preference has always been the latter and remains so, as much for consistency as anything else.
In the days when code editors were much dumber and were little more the text editors it was easier to maintain the "column-style" (the former example) of code. However even then it could be a pain when changes would require manual re-orginisation of code.
But then intellisense and auto-formatting came along and made it really difficult to maintain the "column-style" formatting code. Change something in the line and the IDE automatically eliminated "unnecessary" white-space.
I'm all for readability but not to this extent, stick with latter style.
It's only a matter of readability.
Multiple whitespaces in VB/VBA are ignored.
I'd use the former because it's more readable, but Visual Studio has its own formatting rules and will remove extra whitespaces, so I have to use the second form. :)
This is a coding convention from old C-days, where you had endless structs and you wanted to see the types and variable names starting in the same column. Do as you prefer!
Easier to read, in my opinion. You can clearly see the variable name and type in the former, whilst the latter becomes more difficult with more variable declarations.
I've always hated comments that fill half the screen with asterisks just to tell you that the function returns a string, I never read those comments.
However, I do read comments that describe why something is done and how it's done (usually the single line comments in the code); those come in really handy when trying to understand someone else's code.
But when it comes to writing comments, I don't write that, rather, I use comments only when writing algorithms in programming contests, I'd think of how the algorithm will do what it does then I'd write each one in a comment, then write the code that corresponds to that comment.
An example would be:
//loop though all the names from n to j - 1
Other than that I can't imagine why anyone would waste valuable time writing comments when he could be writing code.
Am I right or wrong? Am I missing something? What other good use cases of comments am I not aware of?
Comments should express why you are doing something not what you are doing
It's an old adage, but a good metric to use is:
Comment why you're doing something, not how you're doing it.
Saying "loop through all the names from n to j-1" should be immediately clear to even a novice programmer from the code alone. Giving the reason why you're doing that can help with readability.
If you use something like Doxygen, you can fully document your return types, arguments, etc. and generate a nice "source code manual." I often do this for clients so that the team that inherits my code isn't entirely lost (or forced to review every header).
Documentation blocks are often overdone, especially is strongly typed languages. It makes a lot more sense to be verbose with something like Python or PHP than C++ or Java. That said, it's still nice to do for methods & members that aren't self explanatory (not named update, for instance).
I've been saved many hours of thinking, simply by commenting what I'd want to tell myself if I were reading my code for the first time. More narrative and less observation. Comments should not only help others, but yourself as well... especially if you haven't touched it in five years. I have some ten year old Perl that I wrote and I still don't know what it does anymore.
Something very dirty, that I've done in PHP & Python, is use reflection to retrieve comment blocks and label elements in the user interface. It's a use case, albeit nasty.
If using a bug tracker, I'll also drop the bug ID near my changes, so that I have a reference back to the tracker. This is in addition to a brief description of the change (inline change logs).
I also violate the "only comment why not what" rule when I'm doing something that my colleagues rarely see... or when subtlety is important. For instance:
for (int i = 50; i--; ) cout << i; // looping from 49..0 in reverse
for (int i = 50; --i; ) cout << i; // looping from 49..1 in reverse
I use comments in the following situations:
High-level API documentation comments, i.e. what is this class or function for?
Commenting the "why".
A short, high-level summary of what a much longer block of code does. The key word here is summary. If someone wants more detail, the code should be clear enough that they can get it from the code. The point here is to make it easy for someone browsing the code to figure out where some piece of logic is without having to wade through the details of how it's performed. Ideally these cases should be factored out into separate functions instead, but sometimes it's just not do-able because the function would have 15 parameters and/or not be nameable.
Pointing out subtleties that are visible from reading the code if you're really paying attention, but don't stand out as much as they should given their importance.
When I have a good reason why I need to do something in a hackish way (performance, etc.) and can't write the code more clearly instead of using a comment.
Comment everything that you think is not straightforward and you won't be able to understand the next time you see your code.
It's not a bad idea to record what you think your code should be achieving (especially if the code is non-intuitive, if you want to keep comments down to a minimum) so that someone reading it a later date, has an easier time when debugging/bugfixing. Although one of the most frustrating things to encounter in reading someone else's code is cases where the code has been updated, but not the comments....
I've always hated comments that fill half the screen with asterisks just to tell you that the function returns a string, I never read those comments.
Some comments in that vein, not usually with formatting that extreme, actually exist to help tools like JavaDoc and Doxygen generate documentation for your code. This, I think, is a good form of comment, because it has both a human- and machine-readable format for documentation (so the machine can translate it to other, more useful formats like HTML), puts the documentation close to the code that it documents (so that if the code changes, the documentation is more likely to be updated to reflect these changes), and generally gives a good (and immediate) explanation to someone new to a large codebase of why a particular function exists.
Otherwise, I agree with everything else that's been stated. Comment why, and only comment when it's not obvious. Other than Doxygen comments, my code generally has very few comments.
Another type of comment that is generally useless is:
// Commented out by Lumpy Cheetosian on 1/17/2009
...uh, OK, the source control system would have told me that. What it won't tell me is WHY Lumpy commented out this seemingly necessary piece of code. Since Lumpy is located in Elbonia, I won't be able to find out until Monday when they all return from the Snerkrumph holiday festival.
Consider your audience, and keep the noise level down. If your comments include too much irrelevant crap, developers will just ignore them in practice.
BTW: Javadoc (or Doxygen, or equiv.) is a Good Thing(tm), IMHO.
I also use comments to document where a specific requirement came from. That way the developer later can look at the requirement that caused the code to be like it was and, if the new requirement conflicts with the other requirment get that resolved before breaking an existing process. Where I work requirments can often come from different groups of people who may not be aware of other requirements then system must meet. We also get frequently asked why we are doing a certain thing a certain way for a particular client and it helps to be able to research to know what requests in our tracking system caused the code to be the way it is. This can also be done on saving the code in the source contol system, but I consider those notes to be comments as well.
Reminds me of
Real programmers don't write documentation
I wrote this comment a while ago, and it's saved me hours since:
// NOTE: the close-bracket above is NOT the class Items.
// There are multiple classes in this file.
// I've already wasted lots of time wondering,
// "why does this new method I added at the end of the class not exist?".
Do languages become more verbose as they mature? It feels like each new version of VB.net gains more syntax. Is it possible to trim down some fat like the keyword "Dim"? C# also feels like it is getting more syntax since version 1.
C# has certainly gained more syntax, but in a way which makes it less verbose.
Virtually every feature in C# 3.0 allows you to do more with less code.
That's the VB idiom. All languages have an idiom, and there are plenty that go for verbose and spelled-out. Thank your lucky stars you're not WRITING IN COBOL.
C# evolved out of the C-like languages, and in the C tradition brevity and terseness are valued, hence braces, && and ||, int not integer, case-sensitive lower-cased code. In the VB idiom, long self-explanatory keywords are good, terse keywords or cryptic symbols are bad, hence MustInherit, Dim blah as Integer and case insensitivity but with a tendency to Capitalise Your Keywords. Basically, stick with the idiom of the language you're using. If you use (or have to use) VB, then get used to the verbosity - it's intentional.
There's nothing wrong with verbosity, in fact it often can be a very good thing.
I assume you have meaningful variable names? Descriptive method names? Then why is there a problem with typing 'end if' instead of '}'. Its really not an issue at all, if anything, the terseness of C# is more of a problem trying to fit as much as possible into as few characters as possible - that means it harder to read, not easier.
Okay... this feels embarrassing to admit, but I like the use of Dim in VB.NET. Yes, it's not serving any particular use that couldn't be inferred by the use of "As" later... but to me, there's something absolutely "beat you over the head" obvious about having declaration statements start with Dim. It means when someone's looking through the code, they don't even have to think about what those statements mean, even for a microsecond. Languages like C# have declarations that are obvious enough, but if you're just browsing by it you may have to consider it for a moment (even the most brief of moments).
There's something "extra obvious" about having a special keyword at the start of certain kinds of statements. In VB.NET, assignments start with "Dim" and calls to methods (can) start with "Call", giving them a kind of "left side uniformity" that If, For, and other constructs already have: you get the barest gist of what's going on with that line just by looking at the very start of it. Using these almost gives you the equivalent of a left-hand column that you can browse down extremely quickly and get the gist of what's going on on some kind of basic level ("Okay, we're declaring things here... we're calling to other things here...").
That might seem irrational or even silly to some people... but it does make the purpose of each statement explicit enough that it feels faster (at least to me) to browse through... especially when browsing through unfamiliar code written by others.
I guess, in the end, it comes down to "different strokes for different folks". I don't mind typing the extra three characters for that obviousness of purpose.
VB.NET is great as it is, it brings more clarity in code.
For instance I love the fact how you can describe what your ending.
End while vs }
End for vs }
End if vs }
And really the verbosity isn't an issue while typing because of intellisence.
Verbosity and readability often go hand-in-hand. Lately I've come to fear the word "Elegant", because it generally translates into "Fun but less immediately readable"
Of course the person writing the code always says "Well it's MORE readable to me because it's shorter/more elegant.
that's crap. It's always easier to read something more explicit unless you have so much trouble reading that it takes you two hours to get through a Dick and Jane novel.
Note that I'm not talking about redundancies, just being explicit and spelling out your desires.
As a programmer it's much MUCH more fun to write elegant expressions, but I've found myself looking at the "elegance" of others and even my own "elegance" after a while and I'll change it to something more explicit, readable and reliable when I realize that although it was fun to write, I just spent more time reading/debugging it than it took to write in the first place.
On the other hand, DIM is just stupid :)
I'm slightly out of my depth here.
I like what everyone calls verbose. Does no one ever wonder my we don't have multiple nested parenthesis in any natural languages (e.g. English)? In fact nested parenthesis really need the convention of indentation to make then legible at all. In natural languages we use verbose clauses and multiple sentences, to avoid, or at least explain layering parenthesis.
Also in a certain sense I wouldn't say vb has much more syntax than c# at all. It doesn't really have many more lexical tokens in a certain block of code than would c# (Does it?). It has about the same syntax as c# it just has longer syntactical tokens, 'End Sub' instead of '}' for example. For most pieces of syntactical plumbing, the VB version will just be more typing (if you are sworn off intelisense), Also '}' is ambiguous compared to 'End Sub' since it also means 'End If' and whole load of other things. This doesn't make it more concise in a certain sense, There are still the same number of tokens in the code, but from a smaller subset of more curt token markers. But different tokens in C# have different meanings depending on the context, which requires you still to have that nested level in your mind as you read the code, in order to get, for example what kind of code block you are reading if you lose your place, even though the end of the code block could be in view you might have to look up to see the beginning of the code block. Even where this is not the case is && really better than AndAlso?
Dim I suppose is quite useless, an extra lexical token compared to c#, but I suppose at least it's consistent with linq, vb doesn't need the var command. I can't think of any other candidates for the chop. Maybe I don't have the imagination.
I'm sure someone is going to come along and tell me how wrong I am :) My best guess this is to do with personal preference anyway.
Then C# should get rid of ";" at the end of every fricking line :)
Default should be easy way to go such "New Line" instead of a ";" if you want exceptions such 2 statements in the same line then you need use a separator such as ":" or ";"
Some people like that. I suspect things like Dim are left in for legacy reasons as much as anything else.
VB does have some nice short cuts though. For example the conversion routines. Eg CInt, CStr etc
OK I'm an old C programmer that came to .Net via C#, and Now I'm working in VB.Net
I have to say at first I was appalled by the verbosity, but having gone back to
C# for I bit, I have to admit I like VB.Net a bit more now.
I can write VB code that reads better and is less cryptic and it really doesn't take
up much more space (especially if you put all your C# curly braces on their own line)
Also the editor in Visual Studio takes care of most of the verbosity for me.
I like how Dim X As List(Of SomeType) reads as opposed to List<sometype> X
Semi-colons are a nuisance now. Curly braces are annoying.
I do miss the square brackets for array refs, a little bit though.
Ever since I saw this...
lowercase keywords?
...I've been hoping it would get included in the language. It's amazing how much more readable it is Without All The Capitalized Keywords.
C# is not a user-friendly language and takes many MORE lines of code to accomplish the same task as VB.Net. Optional parameters, with/end with, etc. are not supported within C#. Even db connections take more code in C#. Star Wars fans love the C# though, as you get to talk like Yoda while you're programming.
My $0.02: VB.Net's intellisense features, shortcuts, logical readability, etc. make it a superior language.
Yes I know what you mean, it can get a bit long winded, I find it becomes hard to read due to there being to too many keywords and making it hard to see the logic behind it all but hey some people like it.
I have just recently started writing all my stuff in C# and I must say I have come to like it a lot more since I just cut of VB and said right C# from now on, so if you are that worried your could always just switch.
Use a pre-processor... and loose any hope to be read by anybody else (or yourself in some years, perhaps...).
I will answer what is often answered to people complaining that Lua is verbose: if you want a concise language, you know where to find it. There are tons of languages around, even if you restrict yourself to the CLR, so why complain about the one you chose? (I know, you might work on a project you didn't started, etc.).
That's not a flame or something. There are many languages for a reason. Some like them super-concise, close of mathematical notations, others like them (more or less) verbose, finding that more readable. There are languages for all tastes!
for one thing that i don't like about VB is this
print("ByVal sender as object, ByVal e as EventArgs");
vs C#
object sender, Eventargs e
Doing so will only make your code harder to read.