EEVblog #86

[charliex]

i looked through the 2.31 code, doesn't look that bad, nice short formatted functions, separated into file groups. I was quite surprised expected it to be a lot worse.

there were quite a lot of commented out code/functions but that sometimes can be ok, not too neat but quite forgiveable for an evolving product.

its ok thats its a a toy, but its not sold as a toy. like the fpga4fun scope is good for getting your feet wet with fpga's but its not expected to actually be used as a scope, then its limited on where you can go with it after that, which is both good in the way its simple, and bad that by simple its more limited than a typical fpga dev board.

[adam1213]

I personally like very high quality code (with lots of abstraction) and about 100 lines per file.
- the dso nanos main function is over 500 lines long.

The reason I am unhappy about the code quality is that bad variable names with global variables not only make the code hard to change but make it very easy to make mistakes.

For example moving the trigger down will cause the software to crash / move the trigger passed the headings.

if((Key_Buffer==KEYCODE_DOWN)&&(Item_Index[V1]>(MIN_Y+5+Item_Index[TRIG_SENSITIVITY]))){
   // other code
   Item_Index[VT]--;
}

[charliex]

Personal preference I guess, 500 is the upper limits but its not terrible, abstraction doesn't seem terribly useful for the dso nano though its a good thing to do in moderation. 100 lines per file would annoy the hell out of me and slow down our compile times like crazy, and it'd be a pain to deal with the source control, so it seems excessive to me. i don't see the gain about having to load a new file everytime i want to look at another 100 lines of code, I typically group them into what the function does, by file, and split them into sub groups if they're getting out of hand. but for a project of 500,000 lines of code, you're suggesting 5,000 files ?

I don't see the problem with the globals, its single threaded and no OS, they're often faster and less code/space, often the same for arrays vs structures, but the proper thing to do is check if its important and what the end result looks like, or even if it matters.

Compared to some of the code i've seen come out of OS projects, or ones like this, it ranks reasonably high. It's fairly easy to read through.

Again personal prefs on short variable names, people prove and disprove the usefulness of things like hungarian notation, i'm a believer in that code out to be readable and understandable with short variable names, if the variable needs to describe what it is, doing, then the code is either overly complex or poorly documented.

I'm sure if you futz around with the code you'll find a million ways to break it, as few asserts here and there wouldn't hurt, but i don't know what the code/data space is like on it, so i can't really comment conclusively about that.

[adam1213]

in my opinion if comments are needed to describe the code then the code could often be written better.
- if the variable names describe what the code is doing so that you don't need comments then you have done well.

- the advantage of having only 100 lines is that you don't have to scroll up and down the file - it fits on one screen. If the file contains a collection of related tasks then you don't have to keep going between files to look at related things.
- also it may speed up compile times (as you only have to compile the files that have changed and then link them together)

Can you please give some examples of projects with 500,000 lines of code.
 - anyway I 5,000 files doesn't sound too bad provided they are put in sub folders (as opposed to a 500,000 line file)

- I know xilinx ISE is very big (~5 gb) in my opinion its because they duplicated code and programs (the installer for 11.1 installs two copies of gcc and java)

[charliex]

There's a difference between people who just auto comment for the sake of it, when the code's perfectly readable and using a typical function header that is parsed with say doxygen, or specific comments that note something thats unusual, or may have an unintended consequence. Generally programmers who don't write function type documentation get too busy to sit down and write proper documents, so it never gets done. A lot of people give out libraries/api's and not source code so its very useful to have well documented code that can be parsed. Its a nice structure.

There are varying arguments on each side of using expressive variable names to describe what something does, i follow the answer you gave about comments since effectively its the same thing, you say if it needs commentary it probably needs to be written better, of course that entirely misses the part about autodocumenting, then the same goes for variables, if the variables need to be explictly written out as what they are, then it could be better code.

This is a general statement, and not a specific one, so there are of course individual cases where extensive variable name is needed, some programmers do write good documentation and get the time to write code then properly document, or have departments that do it. But doing it as you go along means you remember more about the process, you can get people using it earlier and so on. Its a good habit to get into.

100 lines of code isn't hard to work through, there isn't a lot of difference in an editor from clicking a scroll bar, to opening a file, usually the latter is a longer process  and can take up valuable desktop space, which is better suited for looking at code etc.

You're not serious about asking about a project with 500Kloc of code right ? Even it it was  a 10Kloc program, it'd still be an excessive amount of files. Sure precompiled headers help but compilers are faster at compiling one file with a few functions, vs two files with one function.Then you've got all the hassles of source control,  merging etc. Its potential for a  just a huge mess, for a very small return in my view, not scrolling down a page or two ?

[Fezder]

First, sorry about reviving ''dead'' topic, but, slap me in the case of being dumbass...

I'we personally gotten now total of 6 CRT scopes for free, well, 3 are broken, different faults, but i dont discuss about it here, they have their own place. But, i remember first one wich i got, it was supposed to be easy to use, 10mhz/2 channel. Nothing big, my first thought was oh crap, its broken, gotta change it next day. THEN i just saw, density was off, and ray's position was off screen, no wonder nothing showed up!. And, teacher was right, its pretty darn hard to destroy these things, well, its possible yes, to kill yourself with these but you get my point. I messed around with this 10mhz version long time, got used to it like my DMM.
When i helped at school, testing other scopes, many different models, all have same basic idea and ''operating system'' so to say it, pretty easy to use many, or all, once been using one for long time.
Now that i have 150mhz/4chan models, i had to learn again using, theyre pretty different than 2chan models, but now, they are pretty easy to use, well, couple things are still mystery .

Sorry if this post was pointless, just had to say this, dave's video reminded, my starting position was exactly this poor-student-amateur, which doesn't have 300 dollars to spend on scope, no way!. I never used digital scopes even yet nowadays, but i wish someday i have one.