Via MacRumours:
Apparently, Apple has now started labeling their rejection letters with Non-Disclosure (NDA) warnings:
THE INFORMATION CONTAINED IN THIS MESSAGE IS UNDER NON-DISCLOSURE— MacRumours
Apple is really, really pushing the limits of peoples’ tolerance with this now. I love your products Steve & co, but you need to get a grip on this before it becomes a deal-breaking issue.
An interesting article over at ParticleTree on hitting PHP’s memory limit when instantiating a lot of objects
It’s hard to imagine pushing the limits of object oriented PHP so far that your web servers choke, but the truth is those limits are reached faster than you think. — Ryan Campbell
I’ve run into this problem a number of times myself, and always with regards to the example Ryan provides – a script that exports a large database table to a CSV. I didn’t realise that it was the object instantiation that was sucking up all the memory – although perhaps this seems obvious in retrospect.
In the first part of this 2-part mini-series I explained why it is important to make sure you take the time to make sure your code is easy for others to pick up and understand. But how do you best achieve this lofty aim? Below are some general principles that are straightforward to implement and will go a long way to making your code clear, legible and as easy to understand as possible.
Probably the single most important thing you can do to increase the legibility of your code is to inject a good dose of whitespace into it. Dense, cramped up code is hard to scan and hard to extract information from quickly. Correctly indenting your code, together with liberal use of spaces and new lines results in a much clearer easier to scan and understand script. If you are writing JavaScript or CSS, don’t cut back on whitespace to save you a Kb or two in filesize – instead space everything out nicely and then run it through a compressor when you are ready to go live with it all, keeping the uncompressed version for later editing. Have a peek at the CodeIgniter framework source code for a great example of well formatted code with plenty of whitespace.
Good code doesn’t need pages of comments to tell you what it is doing. Careful choice of variable and function names can go a very long way to making your code speak for itself. Stay away from non-standard abbreviations and generic names (like ‘value’ of ’set_value’) where possible, and try to make sure all of your function names are really representative of what the function actually does, and variable names describe accurately their contents. The CodeBetter site has a good post on self documenting code = check it out for loads of good tips.
Nothing is harder to get your head round than code that doesn’t follow a cohesive set of conventions. It is really, really important that you develop a set of conventions (or adopt ones from somewhere else) for all the code that you write, and then stick to them religiously. The actual conventions don’t even matter as much as the sticking to them; what you are aiming for is uniform, consistent code standards across and within projects. This goes for naming of functions, variables, file names – everything, even the amount of whitespace. Write down your conventions if you need to share it across teams – Zend’s ‘coding standard guide‘ for their Zend Framework is a great example of a comprehensive manual of coding and naming conventions. Obviously for your own personal projects it is unlikely you would take it this far; but however far you go it will make it much easier for people who have looked at one piece of your code to pick up another and immediately feel at home.
Comments in code are often invaluable for providing information as to the purpose of a particular line, function or other segment of code. In an ideal world the code itself would be entirely self-documenting (see above) – however in reality this is rarely (if ever) achieved, and a few helpfully placed and concise comments can work wonders. But keep the comments short and sweet! A 30 line comment, unless absolutely necessary, will actually hinder understanding of the code, as it adds to the visual ‘noise’ in the script and most people are highly unlikely to actually read it all! Besides, if a function (or anything else) needs 30 lines of comments to explain what it does it is very likely that the real problem is in the clarity of the code itself.
Whilst it is tempting to condense a 10 line ‘if’ statement into one line by stringing it together into a triple-nested ternary operator expression, this does not necessarily help with the general maintainability or readability of your code! It might get you top geek marks from the most hardcore of programmers, but generally it is not bad thing to split up complex statements to make it clearer to those charged with understanding your code.
Okay, so maybe this isn’t so easy to implement. But the amount of code you write, together with the quality of it go a long way to making it easy to understand (or not!). Stick to the DRY (Don’t Repeat Yourself) principle, and look at every piece of code you write to see how you can improve it and cut down on the number of lines it takes achieve your aim. Shorter, more concise code that fulfills the same role will generally be easier to understand than a long, rambling, poorly written script, as long as it doesn’t break any of the principles outline above.
So these are a just few things that you can do to improve your code’s maintainability, and make it easy for others (or even yourself!) to pick up the code later on down the line and easily make sense of it. No-one is perfect, and I certainly deviate from these guidelines form time to time. But following these general principles will go a long way to making your code accessible to others.
This is part one of a two part mini-series. The second part goes into more detail on tips for improving your code’s readability and maintainability.
The vast majority of developers will, at some point in their career, use code written by a third party. This might be code written by a co-worker, a little snippet from a repository such as Snipplr, or a comprehensive language framework such as CodeIgniter or jQuery.
Now if you have actually ever had to go beyond just using any code written by others, and instead had to delve into the guts of the code itself, you will probably have seen a mix of code quality. Poorly written code can be a nightmare to understand. Well written code, on the other hand, can make it feel like you are reading prose; you can instantly get a feel for what is happening. Typically, well established code libraries will tend to have clear, easily readable code, whereas your co-worker might be turning out code that looks like it is written in Klingon.
So what does your code look like? How easy would it be for other people to pick up your code and figure out what it is doing?
Even if you are working on your own, writing code intended just for yourself, it is important to have a strict coding standard that you work to. You never know in the future who will have to look at your code and figure it out. And even if that person in the future is you, it is amazing how quickly you forget what a particular function or class does. The extra time taken to carefully craft and comment your code so it is easy to pick up again after a break will be paid back a hundredfold when you don’t have to hunt through file after file tying to figure out what your mind was thinking when you wrote it.
If you are writing code explicitly intended for others to use, then the case for clear, expressive code is even more pressing. It is your obligation to ensure that the code is as readable and easy to understand as possible; doing so will benefit you as well as your users, helping to cut down on requests for help or clarification. Good code speaks for itself and needs little documentation.
So how do you make your code easy for others to follow? In the Part 2 of this series I will go into detail on how you can make your code expressive, easy to read and simple for another developer to pick up and understand.
Jeff Croft on web standards and the saga of HTML 5:
The whole concept of web standards, which I once strongly advocated for, has now become so incredibly ridiculous as to be not even worth the time and attention of serious web designers and developers.— Jeff Croft
Jeff was reacting to the techrepublic article where Ian Hickson restated the proposed HTML 5 final recommendation date of 2022. I strongly agree with a lot of what Jeff has to say about web standards; however the problem is that he talks from the perspective of someone who has an excellent knowledge of web standards already. Jeff can knock them down because he has already built them up. The danger is, anyone just starting out in web development, reading Jeff’s comments, may think that the concept of standards is useless – when really the concept is terribly important, it is just the execution that is somewhat flawed.
Whilst web standards and best practice HTML/CSS/JavaScript development are not mutually exclusive, unfortunately in the minds of many developers – especially newer, less experienced ones – they are bound together so closely that they cannot be separated. My fear is that by removing one pillar, the whole house that has been so carefully created from the ashes of the ‘bad old days’ of web development will come tumbling down.
I think any developer who is experienced in web standards should have the right to ignore them and develop to his or her own standard – as long as that is a high one. But newbies must learn the standards first, or with the coming of the next generation the web will be plunged back into the tabled mess of the 90’s.
There is a trend which seems to be growing more and more prevalent on the web, and I have to say it is starting to really piss me off. I’m talking about the practice of blogs only linking to themselves throughout the post, instead of linking to external sites.
This heavy use of internal-linking increases page views across the site – which is probably why magazine-style’ blogs/sites such as TechCrunch, Engadget and Lifehacker do it, to help boost their advertising revenue. Robert Scoble does it, on the other hand, because (in his own words) “… that’s where the good stuff is.”.
What really annoys me about this is that you get ‘trapped’ in a site – you keep clicking through to different pages on the same site, going round in circles, when really what you are actually looking for is some links to external content.
This is at it’s most chronic when the writer wraps internal links around things like company names (or indeed names of people etc); I’m not sure about you, but I would expect a link around a company name to lead me off to that company’s website. That is the most logical and useful behaviour – I want to know more about that company, who they are etcetera, so take me to their site. The web is built off such cross linking. So why break that paradigm and instead link all instances of that company’s name to another page on the same site? Engadget does this as a matter of course, linking names to a page listing all the articles that they have written about the company in question. Nowhere do they ever link to the company’s site itself.
Apart from being annoying for people who are looking for a balanced, multi-sourced view on a topic, this practice is actually undermining perhaps THE most important feature of the web – hyperlinks within text that link not just documents but websites together. The joy (and power) of the web lies in the way it allows the user to meander from site to site, following an information breadcrumb trail with no real idea of where they will end up. Gross misuse of links, pushing all of the href’s internal, breaks this process, preventing the user from moving naturally from site to site, destroying one of the key things that make using the web such a rewarding process.
Obviously, there are exceptions, times where linking to something within the same site is appropriate – but doing it consistently, in places where it breaks the users expectation of where the link intuitively ’should’ go, is a mistake, and a bad one at that.
It’s breaking the web, and it’s really winding me up, so stop it. Now.
From the WebAIM blog:
In the beginning there was NCSA Mosaic, and Mosaic called itself NCSA_Mosaic/2.0 (Windows 3.1), and Mosaic displayed pictures along with text, and there was much rejoicing.
Amusing, biblical-style overview of the history of the mess that is browser user-agent strings.
From the Cappuccino blog:
Cappuccino is essentially a port of the GNUStep frameworks (or Cocoa as more people are familiar with them), and it aims to fundamentally change the way applications are written on the web.
This is a really exciting development in JavaScript framework land, with a completely different take on the matter. It’s hard to think that Apple aren’t kicking themselves that this didn’t come out before they built all their MobileMe web apps using SproutCore.
From the Scientific American website:
Embarrassingly, in the 21st century, in the most scientifically advanced nation the world has ever known, creationists can still persuade politicians, judges and ordinary citizens that evolution is a flawed, poorly supported fantasy.— John Rennie
A good, fairly concise article covering refutations to the standard Creationist ‘arguments’ – all the more relevant with lovely, gun toting, evangelical Christian Sarah Palin running for VP.
(x)HTML @font-face Amazon analogue analytics Apple apps atheism books browsers canvas code CSS css3 dConstruct drag and drop eco electricity email events fail foundries freelancing Google HTML5 IE iphone javascript jQuery miscellaneous mobile MySQL performance personal php programming projects recommendations running Tea The Web tools UI webfonts web standards