MyCodeFactory Blog

1.
It is not an exaggeration to say that everything in Code Model has to be either a literal or have a clear, interpret-able link with Entity/Attribute (or Table/Field if you prefer that terminology). So even variable names should clearly have some association with Base (Default) Model unless those are meant for different purpose. Lets look at this historic pesudeo code fragment to generate unique ‘next’ id. Don’t laugh, this was common during stone age of IT (well, that was some 30-40 years ago)

iLastId = GetLastEmployeeIdFromDB();
miNewEmployeeId = iLastId + 1;

The point here is that iLastId is short scoped and miNewEmployeeId is broad scoped. iLastId would be generated exactly as iLastId in all the modules in Generated Code but miNewEmployeeId would be generated specifically, for example, like miNewCustomerId in customer module. So chances of iLastId conflicting across modules generated by MycodeFactory is likely to be less and there is no issue with miNewEmployeeId as its uniquely named in each module in Generated Code and the model would work well. But it would most likely be a problem had miNewEmployeeId being named as miNewId (because then miNewId would be literally repeated in all modules).

Lets take another example. (This time a real one)
Consider this HTML fragment
<input type=”text” id=txtEmployeeName class=”inputxt” />

MyCodeFactory would be able to associate ‘txtEmployeeName’ with Employee Name field and treat the rest of the text as literal. Such clarity of code is desirable in Code Model.

2.
It also helps if the code containing field name or caption is kept on single line. The lines below are problematic
<label data-error=”wrong” data-success=”right” for=”employeeForm-name”>Join  Date</label>

and should be coded as

<label data-error=”wrong” data-success=”right” for=”employeeForm-name”>Join Date</label>

Conversly, it’d also be helpful if each field is on separate line
<input type=”text” id=txtEmployeeName class=”inputxt” />
<input type=”text” id=txtSalary class=”inputxt” />

3.
Overall, one has to remember that MyCodeFactory is going to attempt to find patterns in Code Model and apply them over the Data Model. So providing a consistent code confirming easy to observe patterns is the key for good Code Model.
And this would apply to white space too. You can’t have one blank line between code related first two fields and then two blank lines for the next field.
While it probably won’t matter to the traditional compiler, MyCodeFactory cannot decide whether you want one blank line or two blank lines between the fields. As a corollary, Don’t leave additional/unnecessary comments that disrupt the pattern in code
For example, compare
<!– Employee Name input–>
<input type=”text” id=txtEmployeeName class=”inputxt” />
<input type=”text” id=txtSalary class=”inputxt” />
with
<!– Employee Name input–>
<input type=”text” id=txtEmployeeName class=”inputxt” />
<!– Salary input–>
<input type=”text” id=txtSalary class=”inputxt” />
The second case would tell MyCodeFactory to add a comment line for each field while in the first case it is not very obvious. So MyCodeFactory may or may not have comments on all text fields in Generated Code in first case.

4.
The Code and Default (Base) Data Model must be in synch. As the Data Model specs the field as EmployeeName, make sure that your code too has it in that way. Empname won’t work for MyCodeFactory.
If you are generating UI related code, make sure that Captions too follow the same rule, confirming the specs. For example, DateOfJoining column has caption ‘Join Date’. So the code
<label data-error=”wrong” data-success=”right” for=”employeeForm-name”>Date of Joining</label>
won’t help. It should be instead
<label data-error=”wrong” data-success=”right” for=”employeeForm-name”>Join Date</label>

The code that goes in the Code Model has to be more than just being syntax confirming  or compile-able in the underlying language. It has to be interpret-able also for MyCodeFactory. Effectively, the Code Model is training MyCodeFactory to produce code in the way you want. The better you train it better would be the results.

Using top quality Code Model is probably the most important thing to make the best out of the MyCodeFactory. Even if a model ‘Looks’ good, you must go through each and every line of code in it before proceeding for Code Generation. As a matter of fact you should subject the Code Model – regardless of whether it is downloaded or developed by you – to the same rigorous quality checks that you would do to any actual application before you deploy the application in production. As the Quality of Code Model is reflected in Generated Code, the efforts are really worth. It may seem very ordinary, non challenging work to a smart developer but it must be done and it must be done in correct way. A bit of irresponsibility or neglect would be magnified manifold in Generated Code.

Good Modeling
Code Model is all about generalization. The Base or Default Data Model is designed to cover most general scenarios and Code Model is expected to be in line with it. Code Model should NOT contain code that cannot be generalized.
For example, a real life application would need to restrict Age to certain range and have validations accordingly even at UX level. But do we need to do the same with Employee Age in Code Model ?
Nop.
Because Code related to Employee Age is representing how to handle numbers. Adding business related rules there would replicate that in Generated Code for all similar fields.

 

To summarize, the Code Model should only contain code that can be generalized and it must be developed as seriously as real life application.

 

The idea of coding automation is around for a while. Probably it is as old as the history of Software Engineering.
The primary approach towards this is by using Code Templates. No doubt, templates work. But that demands lot of patience, efforts and numerous revisions in the cycle of template creation/modification, code generation, debugging and testing.

The core issue with templates is that typically, a template is NOT a standalone working unit of code.

And that is precisely why we have MyCodeFactory.

The entire paradigm of Software Development would change if we can work with a small model of code that can be compiled individually, improved, refactored and refined as an ideal base model which can be used as a blueprint for complex, real development. MyCodeFactory does exactly that.

Before proceeding, let’s summarize the points discussed so far.
1. Template based coding, though powerful, is tedious – first learn the template syntax and then iterations over the complex cycle of template development, code generation, code verification and template improvement.
2. MyCodeFactory takes your working code as Template, overcoming these nuisances.

Now let’s have another look at it from a different perspective.

How do we learn coding?
First we get acquainted with the language syntax, no doubt. Soon we start looking at code samples. We go over various code examples, understand them and then start coding.
Well, MyCodeFactory does it in similar way. It looks at your code example – ‘Code Model’ – and does ‘Coding’ for you.
(Of course, it can’t understand business logic requirements…yet)

In short, MyCodeFactory works with a tiny ‘Code Model’ which is a fully functional/working unit of code – typically as one or more Code Files – that you develop as a normal piece of Software. The main advantages of this approach are:
1. Reduced Development Time-frame
2. Ease of Development
3. Quality of Development
4. Ease of Maintenance, especially in case of making changes across the board.
5. Consequent reduction of Cost over the entire life-cycle of solution.

Among the major decisions prior to actual commencement of Software Development using MyCodeFactory, one has to be clear as to how the source generated would be used in future.
These are the major ways to look at it:
A. To use the generated code as a springboard (only once during start), develop business logic tightly coupled to it.
B. To keep the generated code loosely coupled with business logic such that it can be regenerated if necessary with minimal impact on business logic.
C. To keep the generated code so loosely coupled that iterative development of Models (and subsequent Code Generation) can be easily supported throughout the life cycle of the solution.

Any experienced professional would see very limited use of first scenario and would prefer to go for the other ways and prefer the third option.
And that is where this article wants to help by providing some directions for loose coupling required in the context of MyCodeFactory. In general most of the modern languages provide rich features like inheritance and/or splitting class code in more than one file (e.g., partial class in .net). One can take advantage of such features to keep Generated Code and Business Logic well separated. Of course this decision would be platform/language/solution specific.

1.
Clarity of Code Organization: There must be explicit, specific guidelines for the development & testing teams as to how the code would be organized.
For Development team, depending upon your platform/language, you may be able to keep generated code and business logic in different files/folders or areas within same file (this is not supported at present directly by MyCodeFactory but it would be possible to do that with a wrapper or utility or script in build/CI/CT workflow)
Similar approach is applicable for testing team for organization of generated tests, generated test data and manually created tests.
Practically, this would mean having uniformity in approach that is self evident. For example, if you decide to keep Generated Code in a base class, make sure that the file name has something obvious in its name like as suffix ‘BaseMCF’ (MCF as an indicator for MyCodeFactory Generated File)

2.
Documentation of change management process: When there is a change and new code is generated, how the new code should be incorporated to raise the solution to higher level.
Practically, this would mean clarity on deciding whether Development/Testing teams wait for next version of Generated Code or commence related work simultaneously.
Again this would be highly solution specific and also depend upon the lifecycle stage e.g., you may want to adopt different approach during support stage than development stage.