It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
I am attempting to write a local set of wrapper classes into our institution API (I work at a post secondary institution). The purpose of these classes are to securely pull transcripts from a remote service, and to allow the abstraction away from how that service works to our programmers. How the service works is confidential however the question I need an answer too is this:
How to deal with this when each transcript response comes in a different xml format depending on which of the schools it comes from. There are over 30.
As an example: Institution A has the tag, at the top of the document near the root, for GPA of a student to be |GPA|4.0|/GPA| whereas another institution might have it in a completely different part of the XML, near the bottom and perhaps 3 children deep, and name the tag |GradePointAverage|4.0|/GradePointAverage| (Pretend | is xml angle brackets)
Any suggestions how to deal with this lack of standardization?
It sounds like you should aim for one common data model, and then 30 different classes which are able to deserialize from XML to that data model. Depending on exactly how different they are, there may be significant aspects of reuse, and you may even be able to parameterize some differences. Using LINQ to XML makes it reasonably easy to parse any one format.
I would aim for lots of simple code rather than a small amount of "clever" code: parsing each individual format should be reasonably straightforward, and hopefully easy to test. Yes, it'll be tedious to write this code, but it should end up being easy to follow, and easy to add more formats if you need to.
You could use XSLT to perform a transformation into a single format of course, but personally I'd rather write C# :)
This assumes you can create a common data model - if the formats are very different, you may find that you can't accurately represent the data in each file without having a horrible lowest-common-denominator. Coming up with a good data model is likely to be as hard as writing each individual parser.
Related
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
I am trying to come up with a way to import our current large application into a UML diagram for LucidCharts. LucidCharts supports a vdx XML format from visio. I'm just mainly trying to find a way to do this easily instead of typing each class name and method into LucidCharts. Linking and call chain linking I don't care about as much as I can do that myself.
Are there any easy solutions, or something I can do to read the meta data and make a vdx complaint file?
Actually, there are several open source & commercial tools that will create UML diagram from the C# project and visa-verse. As example, i will try to list three of them:
Option #1: Try to use the Modelmaker. It can work with both Delphi and C#.
I should add that it does more than just diagrams, it can be used for reverse engineering, refactoring and the like. It's been going for a while now and has many great features.
Option #2: You may also try NDepend tool for .NET developers. It comes with both a dependency graph and a dependency matrix and integrates in VS. The graph and matrix can be generated from .NET assemblies and they are interactive. You can download and use the free trial edition for a while and make your own opinion.
Option #3: The Guys at Tigris.org have also done some work on this.
Here is the Open Source Link to the project. It is also very impressive.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
Is there a good practice to split part of complex method's functionality to several smaller methods only in terms of good code readability (but maybe paying some performance for methods calling)? Or this is some kind of "bad style"?
The very basic rule is that your method should do only one thing. If you detect that is doing many different things, then you have a clear refactoring oportunity.
If you reach the point where your method has a single responsability but the size is too long anyway, try to extract "helper" functionality to separated methods. You might even detect code that can be promoted to separated classes.
TDD development is a great methodology to avoid this kind of issues since it really helps to clearly separate concerns and to avoid a bunch of code on single methods just for the sake of testability. If you don't write concise methods, it becames too hard to test them properly.
If you think about reusing code (The DRY principle), you should consider refactoring. Split the method content into different small module based on the functionality so that it can be reusable. Ex : If you have a method which saves a customer registration details and create a new order for him. you could probably check that many methods like CheckUserExist, SaveUser and SaveOrder. You should be able to reuse this functionalities in other areas of your code as necessary. Splitting it into modular pieces makes your code more readable too.
Unclebob (Robert C. Martin) considers that methods should be no larger than 4-5 lines of code. His motto, concerning this, is "Extract till you drop". Personally, i believe this is a very good practice.
Visual Studio allows you to extract a method by pressing CTRL+R, M.
in addition to Claudio's answer, there are some SMELLS that if detected, it means that you have to refactor and split your code.
1- non-DRY code: if you find yourself copying/pasting some lines into more than one place, this is a bad smell that needs to be placed in a center placed, and to be called from as many as it should be.
2- Methods with hundreds of lines: any good method should not exceed 50 lines of code, maybe more or less than this number, but rest assured that this method of 346 lines is not a good thing to do.
3- Too many parameters: a long list of parameters in your methods make readability and code quality worse.
4- code invasion: Methods that are using many blocked from another class, should exist inside this class.
Hope that helps.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 11 years ago.
This question has been edited to ask about a specific example as the original question was deemed unanswerable.
Given an application that needs to display information about various objects (including similar and inherited objects) would it be better to pass in base class objects to the display function and allow it to query the object to determine what data to display; or should you just pass in each of the fields by value. The advantage of passing by value being do not need a direct dependency on the objects they representing, thus keeping the display (UI) isolated from the business rule objects.
In general, you should pass the minimum amount of information that a method needs to do its job. For example, if a method is computing a person's age given their birth date, you don't need to pass in the entire Person object, you just need the person's birth date and the current date.
By following the above approach, you keep your methods loosely coupled, which makes them much more maintainable.
In your case, you have to balance whether you need to access a lot of fields of the base classes in these methods, or if you are just need to access a few. If it's a lot of fields, then it may make more sense to just pass the entire object. It's sort of a balancing act between having good coupling (see first part of this answer), but at the same time, avoiding passing tons of parameters to a method.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 11 years ago.
I'm sorry but it seems a very silly question, but if i have a format let it be .epub for example and want to build a class (C# class) that can read it, what should I do. I'm not talking about a certain format or certain language, but I'm asking about building an interface that can read/write this format. vaguely I guess COM object should do this but i haven't dealt with them and get tired of learning any concepts and technology to find that it is irrelevant to my needs. thank you in advance and sorry for this very loose. question
If you know the format of the file then the only specific thing you need to do is create a class that will read/write that format. The internal structure of the class can be represented however you want.
To write the format just use System.IO.FileStream and/or System.IO.StreamWriter. If the file is represented in hex data then use a BinaryReader or BinaryWriter.
The process of reading/writing a file is then just a matter of parsing the data into your internal representation in code, when reading, so you can edit it and then writing out the data according to the file format spec.
Here is a link on file formats just in case. If you have a more specific question ask it and you can get more specific help and/or examples.
EDIT:
If you are looking for the EPUB spec it is Here. I'm afraid that you are going to have to read the spec for any file format that you plan on creating a class for, which can be tedious. I had to do this for PDF documents recently. Just make sure you can understand the spec, look at examples and try different things out when writing/reading. This is really the only thing you can do.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 11 years ago.
This isn't a complicated question. I was just thinking through best practice and thought the community might be able to help.
SOLUTION
Have one file that contains an enumeration. Source control can take care of collisions between multiple projects / developers. If all assemblies are compiled and deployed at the same time, the ID will be unique (if cast to int). Alternatively, we could assign a number to each enum. The enum file will be added to each project via "Add As Link".
Original question
I'd like a unique id that begins at one, is set at design time, and is easy to implement in code to identify different classes. In Visual Studio, we have a Tools / Create GUID. That's convenient, but at 16 bytes it's a little larger than I'd like.
It'd be nice to able to retrieve unique sequential integers from a web service.
Has someone already done this? Does such a service already exist?
One alternative is to have a file that acts as a central register for developers... but I'd rather not if possible. It would be nice to have two steps: 1. create class, 2. assign id. Done.
You can create this yourself if you want, make a web service and generate numbers. If you generate the number at design time, alter your code at design time so that no other program cares what your magic number is.
GUIDs can be created relatively quickly on anyone's computer. This means that you don't have to have some "central" database for numbers, which assists performance of certain applications. Otherwise, use the GUID, which is a globally unique identifier that you can generate at run time and design time.