Really useful tips and guides in all these for UI design patterns and components....
http://www.smashingmagazine.com/2009/06/15/40-helpful-resources-on-user-interface-design-patterns/
Sunday, February 28, 2010
Monday, February 1, 2010
Better Coding Practice - 20 considerable points
Following 20 points which are discussed below are not an expert advice, however,it is based on my knowledge & experience.
It is nice to follow these guideline for better coding practice.
General Guidelines:
1)Write comment for all methods.
2)Please don’t write many lines of code in a single method instead make separate private methods and write into them.
3)When you are writing many if endif statement, write comment after each if and endif statement.
4)When you are writing many if endif statement, write comment after each if and endif statement.
5)do not hard code the integer value in the code file, Write into a configuration file or store into database otherwise its very tough to change later on, if needed.
6)store long messages that need to show to the user in case of error or any condition failure into configuration file.
7)Please check query string value for correct format before storing into variables.
8)When you are instantiating an object and calling its methods, please write some comments about the object & its methods. Give some meaningful name to the object or variables.
9)Generally variable declaration should not be kept inside the try block. Put variables declaration out of try block. Try block is used to execute any method that can throw error.
10)In Page_Load event, please use IsPostBack condition, wherever possible.
11)Please unit test the code at least twice before sending for review or sending to the client.
12)String properties of a control or string variables should not be convert into string.
13)Use StringBuilder instead of string concatenation.
14)Instead of directly assigning the value of lblLinks.Text, Concatenate with StrinBuilder and assign the value of the lblLinks.Text at last.
15)DataSet, DataTable should be disposed in finally block.
16)When you are instantiating any object and it has no Dipose method, the ideal way is to nullify the object (in finally block), this indicate the Garbage Collector (GC) that the object is not going to use so its ready to be disposed. However, there is another thought also. As soon as the scope definition of the object ends, the object is ready to be disposed so GC will automatically takes care of it.
17)If there is no proper use of Catch block, do not use catch block.
18)If try is used and exception is caught, it must be handled otherwise error should be thrown.
19)Avoid variable declaration inside the loop.
20)Don’t instantiate any object that you are not going to use.
Any Additional tips and comments are really appreciated
It is nice to follow these guideline for better coding practice.
General Guidelines:
1)Write comment for all methods.
2)Please don’t write many lines of code in a single method instead make separate private methods and write into them.
3)When you are writing many if endif statement, write comment after each if and endif statement.
4)When you are writing many if endif statement, write comment after each if and endif statement.
5)do not hard code the integer value in the code file, Write into a configuration file or store into database otherwise its very tough to change later on, if needed.
6)store long messages that need to show to the user in case of error or any condition failure into configuration file.
7)Please check query string value for correct format before storing into variables.
8)When you are instantiating an object and calling its methods, please write some comments about the object & its methods. Give some meaningful name to the object or variables.
9)Generally variable declaration should not be kept inside the try block. Put variables declaration out of try block. Try block is used to execute any method that can throw error.
10)In Page_Load event, please use IsPostBack condition, wherever possible.
11)Please unit test the code at least twice before sending for review or sending to the client.
12)String properties of a control or string variables should not be convert into string.
13)Use StringBuilder instead of string concatenation.
14)Instead of directly assigning the value of lblLinks.Text, Concatenate with StrinBuilder and assign the value of the lblLinks.Text at last.
15)DataSet, DataTable should be disposed in finally block.
16)When you are instantiating any object and it has no Dipose method, the ideal way is to nullify the object (in finally block), this indicate the Garbage Collector (GC) that the object is not going to use so its ready to be disposed. However, there is another thought also. As soon as the scope definition of the object ends, the object is ready to be disposed so GC will automatically takes care of it.
17)If there is no proper use of Catch block, do not use catch block.
18)If try is used and exception is caught, it must be handled otherwise error should be thrown.
19)Avoid variable declaration inside the loop.
20)Don’t instantiate any object that you are not going to use.
Any Additional tips and comments are really appreciated
Wednesday, January 6, 2010
Advantages of Jquery
Since past 6months, I am using jquery and its plug-ins, posting this.
* its light weight when compared to other javascript frameworks
* it has a wide range of plugins available for various specific needs
* it is easier for a designer to learn javascript as it uses familiar CSS syntax. jQuery is Javascript for Designers
* Large development community and many plugins.
* It's on Microsoft's radar and they are adding some plugin support and debug capabilities.
* Very good documentation for a 3rd party library.
* Chaining capabilities are very powerful.
* The online documentation is fantastic.
* Performance seems to be very good as well.
* The entire library fits into a relatively small package given it's capabilities.
* The plugin architecture is also very nice for extensibility. 1.
* It's very small, especially when minified, and offers a lot in the core library.
* It's also easy to extend, and has an active community.
* Finally, it's extremely easy to learn; once you've grasped the core concepts you can start coding complex solutions right away.
* its light weight when compared to other javascript frameworks
* it has a wide range of plugins available for various specific needs
* it is easier for a designer to learn javascript as it uses familiar CSS syntax. jQuery is Javascript for Designers
* Large development community and many plugins.
* It's on Microsoft's radar and they are adding some plugin support and debug capabilities.
* Very good documentation for a 3rd party library.
* Chaining capabilities are very powerful.
* The online documentation is fantastic.
* Performance seems to be very good as well.
* The entire library fits into a relatively small package given it's capabilities.
* The plugin architecture is also very nice for extensibility. 1.
* It's very small, especially when minified, and offers a lot in the core library.
* It's also easy to extend, and has an active community.
* Finally, it's extremely easy to learn; once you've grasped the core concepts you can start coding complex solutions right away.
Monday, January 4, 2010
Did you know… How to - - in Visual Studio tips
http://blogs.msdn.com/saraford/archive/2008/12.aspx
Sara Ford gives the daily tips to use the VisualStudio efficiently.
Sara Ford gives the daily tips to use the VisualStudio efficiently.
Raw data access vs ORM
The "fastest" way to do data operations is with a Sql Connection working with a sproc (assuming the sprocs are efficient). Period. Using an ORM like Linq to Sql, Entity Framework, nHib will not make your code run faster. Furthermore, if not done properly, there may be many db calls for a single task - something which would not be an issue with "normal" data access.
Does that mean ORMs are useless? Definitely not. As you said, creating a custom data layer would require a lot of extra coding. And ideally, that would mean a lot of testing. And not just simple unit testing, the number of integration tests should increase too. There's a productivity issue to consider here.
ORMs - when used properly - can maintain a decent performance level (although slower than raw data access) while at the same time promote some patterns that means the overall quality of code would increase. It could promote consistency and easier testability. You could, for example, keep your data access in a repository and the business code in a service layer. That would mean you could unit test your service layer and need integration tests for the data layer. Granted, something like this could definitely be done without an ORM - but it's far easier using an ORM.
ORMs are slower than raw data access, yet they contribute to manageability and testability. I use ORMs extensively and if the performance hit is holding you back, consider that the .Net framework or the JRE is many times slower than raw c code and a lot lot slower than x86 assembly.
My recommendation would be to start using ORMs.
Subscribe to:
Posts (Atom)