On Fri, Feb 24, 2017 at 11:11 PM, Jim Dorrance via 4D_Tech < [email protected]> wrote:
> I think Module + Descriptor + Type is perfect for method names, but not for variables. Hey Jim, thanks for adding your thoughts. I find Module + Descriptor + Type helpful for process and IP vars and arrays in 4D. I've seen plenty of databases with arrays like these: atNames 20+ years ago I think that I even published a tech note with conventions and names like this. Well, we only had 8/11 characters...something like that. And, yes, my naming conventions are the best and all other conventions are Unclean and Must Be Shunned. Then again, I've changed my conventions substantially several times down the years and they continue to evolve. I'm always stupider in the past...really, what _was_ that guy thinking? Sheesh. Anyway, atNames, okay, I get that its a text array and that it stores names. What kind of names? Pets? Children? Businesses? Favorite movies? Countries? Customers? Planets? Birds? Ingredients? Simpsons characters? Pet_Names_at Country_Names_at Company_Names_at ...etc. Specifying the module makes it a whole lot easier to avoid having unrelated code stomp on each other's data. Also, it makes figuring out the code substantially easier. Those are my main reasons. Within a method, I don't use module names for locals as you already know where you are. For the record, everything I've got is in a module. Everything. I don't have a "utility" module - it's a cheat most of the time. What kind of "utility" is it? Put it in there: Text_ DateTime_ ...etc. I do have a System_ module, but it's pretty small. Do I have modules with only one or two methods. Yes. And since I, despite my repeated pledges, brought up variable naming again (mea culpa), I might as well add: * One of the most substantial benefit of conventions is that you get a sort of mental "muscle memory" when naming and looking for things. As such, it's not worth changing without good reason...even for a "better" solution. Then again, change is supposed to be good for your brain...so perhaps that's a good reason. * If you work in a team, work as a team. If the team wants to follow a set of conventions universally, suck it up and get on board. It's better to go along with the group than to insist on your "better" approach. (Well, it's fair to make your case once, but then move on with your life.) With that said, I've seen teams where it was easy to know who originally wrote what just by how things are named. Some teams don't mind that. Personally, I don't care as long as the person includes enough information in the name and doesn't use data pathologically. Here are a few sorts of data pathology common in 4D code: -- Globals: I don't mean scope, I mean use. The same data is used all over the place, so there's no real way to know where it "belongs", where it's set or how it's changed. There's simply no way to make code like this reliable, extensible, maintainable, or testable. It's bad in any language. Getters/setters can ameliorate the problem to a degree (recommended), depending on how they're used...but aren't a universal panacea. Tip:V16 workers offer us some radical new possibilities with the language. You can maintain a set of private variables/arrays in there that are only accessible through a callback. It's a lot more like a "closure" than I ever expected to see in 4D. Not sure if that's one of the goals (no mention of anything like that), but it's a natural result of using workers in a particular way. Reminder: GIVE UP ON SET/GET PROCESS VARIABLE and VARIABLE TO VARIABLE, particularly with workers. These commands should never been added to the language and are *very* hard (and expensive) to use safely for dynamic data. Vow to get rid of them in your V16+ work. I don't have them in any of my code. Ever. (I do accept that there are a narrow set of cases where, properly used, they were handy for quick data swaps from the server, but we've got better tools now.) -- Brittle execution paths: Things break (hard) when an expected execution path is not followed exactly. This is a *sure sign* that you've got a pathological use of data. It's not that hard to use data without a startup/start process initialization routine or without calling a ton of support code in the right order. That's a couple. We've all seen it...I'd expect that we've all done it. * We need more than 31 characters...and now I know how to vote for feature requests (thanks again to Tim Penner): Raise the 31 character name limit on methods http://forums.4d.fr/Post/EN/18946884/1/18946885 Need more votes. It's currently on 4/4 stars with 28 votes. And, while you're there: Automatically Associate C_Object With Form Objects (and the Window) http://forums.4d.fr/Post/EN/19051683/1/19051684 Currently on 4/4 with 19 votes. Given this is the best feature request for the language I can remember seeing in years, it needs more votes. ********************************************************************** 4D Internet Users Group (4D iNUG) FAQ: http://lists.4d.com/faqnug.html Archive: http://lists.4d.com/archives.html Options: http://lists.4d.com/mailman/options/4d_tech Unsub: mailto:[email protected] **********************************************************************
