The only built-in entities in XML are &, <, >, " and ' XHTML added the others via a DTD that is not a part of HTML5. As such, validators will report them as errors.
Safe replacements are the decimal notation:   or the character itself U+00A0;
Quite a few other common symbols are not available without similar changes.
< = <> = >& = &' = '" = " –  © = ©® = ®™ = ™
REFERENCES:
Categories: WebStandards, Work Tags: amp, code, copy, entity, escape, html, html5, i18n, l10n, nbsp, quot, reg, trade, unicode, validation, xhtml, xml
I’ve been a huge fan of the ‘final‘ modifier in Java for function arguments and variables. While there’s some debate on their usefulness for performance, they definitely add in readability and understanding of code as developers are instantly notified by modern IDE’s and when they try to reassign such values as the compiler will indicate the error.
NOTE: Use of final for classes or functions often contradicts the paradigm of Object Oriented programming as you’ll be restricted from extending or overriding those items!
Categories: Work Tags: argument, code, compiler, final, ide, j2ee, java, keyword, modifier, performance, value, variable
About a year ago I wrote a post regarding JSLint usage for code quality of JavaScript. There is now,for a while actually, an open-source fork of that code that allows for greater configuration.
Oddly, there are two separate sites, but I believe that they have the same content:
I’ve found that many developers still use the classic coding style on JSP’s, unfortunately this makes it difficult to use some common tools for validation and complicates matters when looking for improperly nested tags in the markup. Migrating the XML formatted JSP markup simplifies matters and makes it possible for developers to quickly identify many problem areas of code within the IDE.
<%@ page language="java" %> = <jsp:page.directive language="java" />
<%@ page contentType="text/html; charset=utf-8" %> = <jsp:page.directive contentType="text/html; charset=utf-8" />
<%@ page import="" %> = <jsp:page.directive import="" />
NOTE: you can combine page.directive’s to a single tag with all attributes.
<% //some scriptlet %> = <jsp:scriptlet>//some scriptlet</jsp:scriptlet>
<%! String somevalue="1"; %> = <jsp:declaration>String somevalue="1";</jsp:declaration>
<%= somevalue %> = <jsp:expression>somevalue</jsp:expression>
<jsp:include page="" />
<jsp:directive.include file="" />
<jsp:useBean id="" scope="" type="" />
<jsp:setProperty name="" />
Unfortunately, there’s one common type of tag that does not have an XML equivalent:
<%@ taglib prefix="c" uri="/WEB-INF/tlds/c.tld" %>
REFERENCES:
Happy coding
Categories: WebStandards, Work Tags: code, coding, html, ide, jsf, jsp, jstl, nesting, tag, taglib, validation, xhtml, xml
I’ve programmed in a lot of different languages, and with various IDE’s. The one area that has always been lacking is a simple means to review JavaScript code for common errors, both syntactical and format. This is where JSLint and JavaScript Lint come in…. these represent the tooling previously available to other languages like C++ and Java, where you can analyze code without actually executing it to identify problem areas. Often, these are items like ‘missing semicolons’ that occasionally cause difficult to find errors in browsers.
These can be scripted to execute from the command line or within (some) IDE’s on several operating systems.
Categories: WebStandards, Work Tags: code, data, error, files, javascript, js, jscript, jshint, jslint, lint, quality, recover, review, salavge, script
I’ve previously written on the benefits of static analysis of java code with the use of PMD and FindBugs. I was recently turned on to a new tool that performs similar testing of code within the Eclipse IDE.
When I first found this tool it was free, since that time it’s come out of beta and is now a little costly, but it may still be worth it due to the functionality it provides.
The premise of this tool is a little different than other ones, while it covers much of the same need, it also performs many tests that I would previously use CheckStyle to do. This only provides them at runtime and in a common manner within the IDE.
REFERENCES:
Cheers!
Categories: WebStandards, Work Tags: analysis, code, eclipse, ide, java, javadoc, performance, plugin, standards, static
As an old UNIX developer, I spent a significant portion of my work experience using VI, as my development environment became more focused on Windows, I used Homesite for developing text formatted documents. I’ve found that the current offerings from Eclipse and other IDE’s are notoriously bad at displaying the source of many document types, particularly JSP, HTML, XML, JAVA, JS and CSS files; where you often want to see exactly how a document is structured. Additional spaces, tabs and carriage returns can cause display formatting issues and wasted bandwidth in many cases.
Many of my peers are fans of TextPad, but I’ve found Notepad++ to be quite up to the task:
- it is available for Windows and LINUX
- supports auto-formatting of many text file types
- can ‘replace’ the default Source-HTML viewer in MSIE.
http://notepad-plus.sourceforge.net
Happy coding!
I recently found out about ’static analysis’ of Java code. I’ve found two of these tools that are both free and easy to use. Both provide review of java bytecode and look for common development errors and inefficiencies…
FindBugs is based on the concept of bug patterns. A bug pattern is a code idiom that is often an error. Bug patterns arise for a variety of reasons:
- Difficult language features
- Misunderstood API methods
- Misunderstood invariants when code is modified during maintenance
- Garden variety mistakes: typos, use of the wrong boolean operator
PMD scans Java source code and looks for potential problems like:
- Possible bugs – empty try/catch/finally/switch statements
- Dead code – unused local variables, parameters and private methods
- Suboptimal code – wasteful String/StringBuffer usage
- Overcomplicated expressions – unnecessary if statements, for loops that could be while loops
- Duplicate code – copied/pasted code means copied/pasted bugs
Both integrate easily within Eclipse based (and other IDE’s) is typically done with the use of a simple plugin.
FindBugs can also run as a Java WebStart (JNLP) application, however a different UI is shown for JRE 1.4 vs. 1.5 and above (look out!).
More information:
While no tool can identify all problems, these will help you find some troublesome problems and give you areas to take a deeper look at.
Happy reviewing and fixing.