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.