My company has decided to try to start curating our “best” templates from all our projects and decding on how in the general we want to design our templates across our projects, so that one developer can pick up where another left off with minimal re-reading of the code required.
To start this off we are going to have everyone pick their favorite “valve” template next week and we’re going to discuss what we like and don’t like about each one and based on that try to make some design decision that we will try to use across all our templates.
Personally I think us coming up with guidelines and conventions will be way more helpful than a template library as we have projects with different versions all over the place and no project requirement is exactly the same.
What’s your opinion about templates/best practice methodology?
I have a few points I want to made -
Template parameters must have some naming convention, given that they are the only way to both input data to the template and get data out of the template. I’m of the opinion that template parameters should be named things like “in_somePropery” “out_someProperty” so people know what they have to provide and what they are getting without any additional reading of the code required.
All non-inputs/outputs should be hidden inside the template.
To UDT or not to UDT as a paramter? We have a bunch of templates that work with a specific UDT structure, and that seems ok until you take it to another project that does not have the same UDT strucuture. I think perhaps the “in_” parameters should be bound directly to the property of the UDT and then you can always template repeat anyways, this way even if you have two differently shaped UDT’s with different property names, you can still utilize the same template
Templates should be as encapsulated as possible, templates should not rely on windows or other components to do calculations for it (something I’ve seen that made my pull my hair out), if you need something done within the template there should be a parameter that’s changed to do it and that’s it, no outside work necessary.
The proper level of abstraction - this is a tough one. I’ve seen many templates that accept database table names/columns for read/write capabilities, and I see the use in it. Is there an argument against this? I even saw a template that passed on full on queries and dataset to pass onto a popup window that would be run with the submit button on the popup was pushed. While I can see the convenience if you can get it working right and know how it works, it did take me a while to understand and would take a while for another developer to understand before using.
Do you put all your properties on the root container? One coworker brought this up so that way everything is there for looking at, and you don’t have to parse the components to see where things are coming from. I’m used to doing things like putting a “whereClause” property on every component that contributed to a where clause in a query, but I can see how it might be confusing, but at the same time I hate when root containers are over populated.
Thoughts? I know this isn’t the the typical question for this forum but as developers I’m sure many of you have lots of opinions about this and I want to hear them.