It’s generally recommended to avoid hardcoding when you build a piece of software, but some programmers have gone extreme in this direction that they try to avoid hardcoding at all costs, even if the cost of hardcoding is actually smaller than the cost of their alternative. I think it’s safe to say that some programmers started using XML as a programming language!
It seems the trend nowadays is to use Java style garbage collection for all sorts of memory allocations, which makes life easier for the programmer, but does that mean it’s the right approach?
There used to be many naming conventions back in the days, but lately it seems that two conventions are emerging as the two most popular among programmers. Underscore naming convention and camel case naming convention. Someone might argue that there are other popular conventions, but for now let’s compare these two and ask programmers out there which one they prefer. In the end a programmer might be bound to whatever is the standard for the language he is using, but this doesn’t prevent us from doing an out-of-context comparison.
Everyone is concerned about the security of their systems, and all sorts of protection softwares are installed to make sure no code is allowed to run on their machine outside the boundaries of the web browser, but is this the right approach? Most people would say yes, but consider the following real-life scenario:
Generating PDF files can be done by calling iTextSharp classes and methods directly, but consistency with the rest of MVC is preferable. In this post I’m going to explain how you can use iTextSharp to create PDF views the same way HTML views are created. What we need is to write our PDF files under the Views directory using a markup language. iTextSharp supports a special XML format that can be used in our views instead of HTML. One thing to note about aspx is that your tags don’t have to be HTML tags. You can type anything you want; of course Visual Studio will only recognize HTML but the ASP engine will spit that data out to the browser anyway. So, we are going to use regular views but we are going to write iTextSharp XML tags in them instead of HTML. Then we’ll need a way to intercept the result and convert it into PDF before it’s sent to the browser.