3
I have a question regarding the following code snippet:
public enum TipoPessoa
{
[System.Xml.Serialization.XmlEnumAttribute("1")]
Fisica = 1,
[System.Xml.Serialization.XmlEnumAttribute("2")]
Juridica = 2
}
or that:
[System.Xml.Serialization.XmlEnumAttribute("11")]
Item11 = 11,
I have read in some questions this is absurd.
What’s wrong with these code snippets?
7
I have read in some questions this is nonsense. What is wrong in these code snippets?
Nothing. I don’t know what is so absurd in the answers you’ve been reading.
The only thing this decoration does is force the XML serializer to use the given values instead of using the representation string of the value of enum.
3
An enumeration is a sequence of constants. In general constants must have their immutable state throughout the life cycle of the project (the answers in this question give the details). Eventually you can add something new in the end, but no more than that, even so it doesn’t always work well, even if very well documented.
If a data can be modified, even if between versions of the application the ideal is that it is not actually constant, it is better just to be immutable.
π (Pi) is a constant. A code that depends on legislation is not a constant. It is a data that at most does not change during the execution of the application, but not during the whole life cycle of the project, it is not constant.
Data that is not constant is already problematic when treated as if they were. It becomes more complicated when these constants are in sequence. Makes it harder to secure status.
Enumerations are programming mechanisms. No compilation mechanisms. Do not serve to validate business rules.
This example takes parameters and turns them into constants. Big mistake.
There’s one more question that talks about the abuse of enum in database.
So an enumeration has to be something that you have control of, that you know won’t change.
What kind of person is legal or physical something internal to you? Can you guarantee that it will always be that? Does it affect anything external? So no problem in doing.
Or is it something defined by legislation? Is there no guarantee that legislation won’t change? If you don’t have control, don’t go for something constant. Do something that explicitly indicates you can change. Use a data structure conducive to change. Even if it never changes, it will be a fluke, the semantics of the data is that it can be changed, so represent it appropriately.
The same goes for the Item11. There is no context of what it is, but it seems to be something that depends on legislation (the question is without context, many people will not understand that the original speaks in Nfe (has a worse case).
The best explanation for this is this ID that everyone uses in a database. Because you use a ID and not the person’s CPF, for example? Because there is no guarantee that this person will not change the CPF. You create a substitute to refer to that. You don’t use the CPF because you have no control over it. The same goes for a supplier product code, email, or things like that.
If you change and your application was made thinking that these data are constant it will be a nightmare to maintain it. A small change in legislation (and there has already been a change that has changed all) can cause the whole system to stop working and to fix will have to redo it.
It can be worse, a change to go unnoticed. It may look like it is working but it is generating all wrong result. Imagine a change of order. When data can change you need to have a canonical reference to it within your system that does not depend on external information.
Make the system ready for change.
People need to understand that systems don’t just have to "work". They need to be conceptually right to support future maintenance. If a data is part of a mutable table, represent it as a mutable table. Choose a dictionary or another data structure more suitable for this. You can even create your own structure if it’s beneficial. But don’t use a constant structure.
Note that these dictionaries may be filled with data from the database. Or even the database will be used to provide what you need directly.
The fact of wearing [System.Xml.Serialization.XmlEnumAttribute("11")] already shows that it is the wrong mechanism. The real data is a text. An enumeration does not represent texts, it represents numbers. This is an attempt to fix the initial error. And it’s another mistake. Hence we conclude that errors attract errors. It only gets worse.
I didn’t even talk about the readability of the code. Think an enumeration called TNFeInfNFeDetImpostoICMSICMS00CST Is there anything in the code? Can anyone say what it is without fear of making a mistake?
Browser other questions tagged c# enums
You are not signed in. Login or sign up in order to post.
I have never used this [System.xml.Serialization.Xmlenumattribute("1")] on an Enum
– PauloHDSousa
Where you read that this is nonsense?
– Jéf Bueno
@jbueno probably read a comment from me in another post, in a completely different context (with data from business rule), and asked here (but I’m not sure) - It would be good for Reis to put a link there if this is the case, to give more context. Follow link: http://answall.com/questions/154069/xsd-para-classe-c-enum#comment318055_154069
– Bacco
I came to think of it after I saw your comment in the other post @Bacco
– Jéf Bueno
It would be good for Reis66 to put the context and explain what he wants. My answer was based on what seems to be what he asked. The statement that it is absurd is not about the use of the serialization attribute, but the use of enumeration. So the most voted answer seems to me not to be about what the question is talking about. As the question has no context everyone got confused.
– Maniero
It is a right of the PA to accept the answer you want, but it seems that the question is not clear at all. The question speaks in "Enum value". The accepted answer talks about the attribute associated with
enum. The question asks clarification on what makes it bad by stating that other answers cited it. The answer accepted does not talk about it. The question was quite confused. Apparently the question did not really want to know what was asked.– Maniero