Re: Coding/Development Style Guide?

t: Tuesday, December 18, 2018 7:43 PM > To: 4D iNug Technical > Cc: Jody Bevan > Subject: Re: Coding/Development Style Guide? > > Tom: > > We rewrote our shell for v16 from scratch. I also wanted to write complete > documentation on using the shell too. That

Re: Coding/Development Style Guide?

Technical Cc: Jody Bevan Subject: Re: Coding/Development Style Guide? Tom: We rewrote our shell for v16 from scratch. I also wanted to write complete documentation on using the shell too. That of course included naming convention for everything (even table names), includes lots of code that is very

Re: Coding/Development Style Guide?

Tom: We rewrote our shell for v16 from scratch. I also wanted to write complete documentation on using the shell too. That of course included naming convention for everything (even table names), includes lots of code that is very easy to add to code you are writing, and explanation of a lot of

Re: Coding/Development Style Guide?

And one that I’ve seen frequently: there are 10 kinds of people in the world: those who understand binary and those who don’t. Jeremy > On 17 Dec 2018, at 03:51, Tom Benedict via 4D_Tech <4d_tech@lists.4d.com> > wrote: > > >> On Dec 16, 2018, at 14:24, Kirk Brooks via 4D_Tech

Re: Coding/Development Style Guide?

> On Dec 16, 2018, at 14:24, Kirk Brooks via 4D_Tech <4d_tech@lists.4d.com> > wrote: > > Remember what they say, there are only 2 hard things in writing code: > naming things, clearing the cache and the off-by-one problem. > That reminds me a signature I’ve seen thousands of times here. "There

Re: Coding/Development Style Guide?

This says it all... https://www.itworld.com/article/2823759/enterprise-software/124383-Arg-The-9-hardest-things-programmers-have-to-do.html#slide10 Dani Beaubien Open Road Development > On Dec 16, 2018, at 3:24 PM, Kirk Brooks via 4D_Tech

Re: Coding/Development Style Guide?

I agree with Peter. Object names need to convey what their purpose is, at best, and be as unambiguous as possible at least. The size of the method has a lot to do with how ambiguous a name might be. I have no qualms about using $i as an index counter in a method where there is only one loop or

Re: Coding/Development Style Guide?

On Sun, Dec 16, 2018 at 10:15 PM B.Bippus via 4D_Tech <4d_tech@lists.4d.com> wrote: > Begin each variable name with a character to specify what type it is: > · String: s > · Text: t > · Boolean: y > > To add the Variable Type to the Variablename is a big help. I started many > years

Re: Coding/Development Style Guide?

Begin each variable name with a character to specify what type it is: · String: s · Text: t · Boolean: y To add the Variable Type to the Variablename is a big help. I started many years ago to prepend the Type. And I am using the "4D Pop Marco Declaration" to automatically declare

Re: Coding/Development Style Guide?

Tom, Back in the day (haven’t checked with recent versions of 4D), you could create/modify/save a template Form in the 4D Form creation tool. Isn’t that what you are talking about doing here? Thanks, Walt Nelson (Seattle) New stuff coming! www.foundationshell.com w...@foundationshell.com >

Re: Coding/Development Style Guide?

> Le 14 déc. 2018 à 18:35, Tom Benedict via 4D_Tech <4d_tech@lists.4d.com> a > écrit : > > Hi Chip, > > Thanks for pointing out that forms can be inherited. I still have inherited, but in recent jobs I use subforms instead. They offer more solutions to design "shared parts" of UI. --

Re: Coding/Development Style Guide?

Hi Chip, Thanks for pointing out that forms can be inherited. I’ve looked at Inherited Forms in the past and they struck me as having limited value since they cannot be modified on the child form. Record navigation and CRUD buttons are simple and can been generic, but custom features,

Re: Coding/Development Style Guide?

Tom, They do - you can create a form and then inherit it. Form properties -> Inherited form table --- only if the form is from a table Form properties -> Inherited form Name This is what I do for list forms when I need to add functionality different from my base list form. Chip On Fri, 14 Dec

Re: Coding/Development Style Guide?

Thanks Pat and Arnaud, Seems it’s common to include datatype in variable/field names, whether it’s prefix or suffix is a matter of style. I find it very useful to know at a glance the type of an object, so I use a similar “modified Hungarian” notation too. For booleans I use the “is” prefix,

Re: Coding/Development Style Guide?

no - I probably should... my UI is fairly simple in design: - color coded entry areas -- Black - optional -- Red - non enterable (display only) -- Green - mandatory I use the same record navigation buttons on all forms : Philadelphia from 4D v2003? these are arranged vertically on the left

Re: Coding/Development Style Guide?

Thanks Chip. Very comprehensive! Do you have a similar guide for User Interface? Tom > On Dec 14, 2018, at 08:18, Chip Scheide <4d_o...@pghrepository.org> wrote: > > > you asked for it :) > > here is my 'conventions' comment only method - > I place this in every project. > > > On Fri, 14

Re: Coding/Development Style Guide?

you asked for it :) here is my 'conventions' comment only method - I place this in every project. //Project Method: _Conventions // • Created 2/16/10 by Chip - //• Updated 2/17/16 by Chip - //• Updated 3/24/16 by Chip - //• Updated 9/2/16 by Chip - added object naming, popup

RE: Coding/Development Style Guide?

Pat, Love the j for object. I had been trying to figure out what I wanted to do for that and hadn't yet. Thanks for the idea. Justin ** 4D Internet Users Group (4D iNUG) Archive: http://lists.4d.com/archives.html Options:

Re: Coding/Development Style Guide?

> Le 14 déc. 2018 à 16:48, Pat Bensky via 4D_Tech <4d_tech@lists.4d.com> a > écrit : > > We have a family simple but effective set of rules for naming variables. > [...] Hi, we're using something similar for variables (except it's suffixes: myText_t, myDate_d, myTwoDimentionalArrayText_a2t,

Re: Coding/Development Style Guide?

We have a family simple but effective set of rules for naming variables. It's easy to follow and easy for anybody to know immediately what type of variable it is: Variable Naming Conventions Begin each variable name with a character to specify what type it is: · String: s · Text: t ·