Is it good style that calling setters follow the same order as XSD elements? [closed]

Question

In the project I work on we use XSD to generate some classes. XSD determines the order of elements, similar to this snippet:

<xs:element name="Customer_ID" type="com:Text6"/>
<xs:element name="Customer_Desc" type="com:Text150"/>
<xs:element name="Customer_Name" type="com:Text50"/>
<xs:element name="Institution" type="com:Text150" minOccurs="0"/>
<xs:element name="Scheme" type="com:Text50"/>
<xs:element name="Country" type="com:Country"/>

One colleague created some tests in which he sets object fields in different order comparing to the order in XSD, for example:

obj.setCustomerName("name");
obj.setCountry("EU");
obj.setScheme("scheme");
obj.setCustomerDesc("description");
//etc.

Furthermore, he uses different order in different tests. I argued that we should stick to the same order in code as it is in XSD because that way it's easier to read or change code/XSD. He thinks it's nitpicking because, at the end, object will have its fields initialized anyway.

I'd like to hear your thoughts - is this really nitpicking from my side or not?

Answer 1

The fact that you are using XSD is not important. You are creating Java classes and those don't care the order (well, unless there is some dependency that should be dealt with in the constructor or a builder, rather than through setters). Keeping them in order because of the XSD can end being a maintenance nightmare, as any change on the class/schema could mean reordering every single place where you use your setters

Answer 2

Whenever I'm doing some tedious task, like making a new X object and setting 20 of its properties I tend to do so in alphabetical order, because that's the order I see things in the IDE's intellisense/code help combo dropdown - helps me avoid missing one. I'd be tempted to sort and update XSDs similarly, inserting new elements in an alphabetical order so long as there wasn't a declared sequentiality, but in these days of "search trumps navigation" I'd be more likely to Ctrl-F or some IDE based "goto reference/implementation/declaration" function than look at things and want them to be in a certain order so I wouldn't care so much if a fellow dev had a different take on ordering independent statements

Perhaps leverage a search approach more, then you'll care less about things such as this, or become responsible for the coding standards at your organisation then you can write the rules. (Beware of writing rules that go contra to the generally accepted/easy way of doing things - look how many years the Highway Code has been telling us "only flash your headlights to let the other driver know you're there" when everyone always and forever will have it mean "proceed with the course of action I assume you're going to make; if you surprise me I can always give you the horn and the finger")

Answer 3

You don't say what the container for your elements is.

if you use a <xs:sequence> then the order of the elements is enforced.

I had a look and can't see what if any conditions are present if you just use schema I guess from your question no order is enforced.

On the whole xsd is a complex tool and defining classes through its use could get tricky if you are going to be strict with it. That's part of the reason for the switch from xml to json.

Also, in this case he is simply setting the values on the objects. not defining them.