Re: Interesting IDE hiccup
toggle quoted messageShow quoted text
"I guess he didn't understand the difference between compiled and interpreted code..."
HA! There are a lot of people who don't know this, but at the same time, I don't want to discourage them from playing around with the code. Often a heads-you-win-tails-I-lose thing.
From: Dennis Zabawa <kg4rul@...>
Sent: Saturday, January 20, 2018 1:04 PM
Subject: Re: [BITX20] Interesting IDE hiccup
Quoted from Jack W8TEE:
"True, the person writing the code has to be a little more organized, but it actually benefits the users of the source files. There needs to be a header file so that globals can be handled correctly but, again, you probably need that anyway if you want to do type checking on your code (and you should).
If you comment your include files and date your source files, there should be no reason mutli-file projects are any more difficult to manage than single files. When it comes time for me to distribute this project, the burden on me is upped a little bit, but I've already gained more than that back in the time saved for the reasons mentioned above. As far as the user, they really should see no difference if I've set the ZIP file up correctly."
This is SO TRUE! I have seen SO MUCH Arduino code, especially libraries, that have virtually no commenting and use non-descriptive variable and function names. I tend to spend time describing just what the code does in my comments and providing descriptive naming so that I can come back later and understand how it all works.
I have to add that I come from a background where projects encompassed millions of lines of code and extensive documentation. I once published some Arduino code and had another "programmer" come back to me with a version that had no comments and extremely short variable and function names. His claim was that it ran faster. When I asked his background, he informed me that he was a Basic programmer. I guess he didn't understand the difference between compiled and interpreted code when it came to run-time.
Take the time, do it right the first time.