|
To answer my own question, the answer is yes....it is possible to fake (or mock) any .NET method using delegates using Moles as in the Pex and Moles[^] framework.
Here's an example[^] of exactly what I need 
Pretty cool 
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
I have spent many years working with various build tools, with a particular emphasis on creating continuous integration (CI) environments. I have worked with Nant, MSBUILD, Cruisecontrol.NET, TeamCity, Git and Subversion to name a few. I have configured automated tests as part of the build process using Nunit and automated the signing and packaging of an Android app, all using various build and CI tools.
So I have a pretty good understanding of the build process and the tools and environments that support it. For this reason I haven't used the Application Lifecycle Management (ALM) features found within Team Foundation Services (TFS) as I haven't found them to be best-of-breed. However, that was then, and this is now. I've recently been using the latest build features in TFS 2015 and have to admit that I'm very impressed with them.
They are very much improved from previous versions of TFS. One of my biggest criticisms was that TFS only really worked within the Microsoft build tools ecosystem, and didn't play particularly well with other build tools and systems. That's all changed in TFS 2015 though. The build tools in TFS 2015 now support practically any build tool or platform you care to mention. Git, Maven, Nant, Android, iOS, scripting languages etc. The list of supported tools and platforms is extensive and impressive.
I managed to get a complete build setup and configured with ease. This included a full build, continuous integration triggering from TFS and a deployment to our development server. From code being checked-in to being deployed on the test server is all automatic and takes just a few minutes to run.
This is an ideal build solution for anyone looking to automate and simplify their build process and which is capable of supporting many different build tools and platforms. The Rolls Royce build solution is still TeamCity, but this an impressive build platform nonetheless and one that I am happy to keep using.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
I've recently been using Telerik Platform for mobile development, so I thought it may be useful to give an overview of my experiences, especially as I've previously used Xamarin for mobile development.
For those that don't know, Telerik Platform is a complete mobile development ecosystem consisting of a suite of Telerik technologies rolled into a single unified platform. There are tools for development, testing as well as backend services such as data services, email / SMS services and business logic services, analytics and user management. All of these are accessed from your Telerik Platform account (depending on your subscription level of course).
The backend services may be implemented in your app using any combination of the folling APIs and SDKs.
- Javascript SDK
- .NET SDK
- iOS SDK
- Android SDK
- RESTful API
As can be seen, all mobile platform development environments are available to the developer.
All the tools you need across the entire lifecycle of your mobile app are all accessed from a single location. Unlike other development platforms, Telerik Platform is more than just a development tool, it contains the full complement of tools to manage the entire lifecycle of your app.
There are two key options to choose from when deciding how to build your app. You can choose either a hybrid app or a native app. I won't go into the pros and cons of the different approaches as this is beyond the scope of this article. Suffice to say that if you opt for a hybrid app you are using Apache Cordova. If you opt for a native app you are using Telerik NativeScript. In my case I was building a hybrid app. The reasons were as follows:
- We wanted to target all mobile platforms (at the time of writing NativeScript does not support Windows Phone)
- The app was fairly straight-forward with limited access the device's capabilities
- The learning curve was less steep due to the fact that a hybrid app employs web skills such as HTML, CSS and Javascript, all of which are familiar to me. The areas where I was less familiar was with using Telerik's Kendo UI components and the underlying MVVM architecture. Thankfully there are numerous examples and documentation, and being a competent web developer I picked these up fairly quickly.
The backend services are really a powerful addition to the development experience. The option of using these from the cloud reduces the reliance on local infrastructure, such as data and email servers. You can build your entire app from their cloud portal. There is a Visual Studio plugin you can download, which is useful, but I predominantly used their cloud portal.
One of the best things I enjoyed about Telerik Portal is their AppBuilder technology. This allows you to test your app in a simulator with varying combinations of platform (Apple, Android, Windows) and screen resolutions. And best of all, you can download the app to your own device using the Telerik development apps. Building your app generates a QR code. This QR code is then scanned using your device using the Telerik development app, which then copies the app to the device. No pesky USB cables or installing/configuring emulators are required. This is a genius piece of technology. Your code changes are reflected immediately in the simulator, and can be tested on the physical device by simply swiping the Telerik development app. From coding to testing on a physical device has never been simpler.
All in all I have been very impressed with Telerik Platform, and would certainly recommend that it be included on your list of candidate development platforms if looking at going into mobile.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
modified 8-Jul-16 15:42pm.
|
|
|
|
|
Whilst recently investigating various mobile platforms with a view to making a decision as to which of the many mobile technological ecosystems we should opt for, it became clear that what was really needed was some direction from the business. Without a full appreciation of where mobile fitted into the company's overall business strategy, it was impossible to gain any real traction on the problem.
For example, having definitive answers to questions such as these is important.
- What are the company's overall corporate objectives?
- How can a mobile initiative help the company in meeting these objectives?
- What does the company hope to achieve by using mobile technology?
Before making any decisions regarding mobile technology, it's important to unsderstand as clearly as possible how the mobile strategy is aligned to the overall business strategy. If the two are not aligned, then do you really need a mobile offering in the first place? Assuming that you do need a mobile offering, it should be clear where it fits into the overall business strategy.
Before embarking on a mobile strategy, it may be useful to know how many of your existing customers are currently using the web version of your application (assuming you have one). This will give you hard numbers to help sell the idea to other areas of the business. It will also tell you what devices your customers are using you so know what mobile platforms to target.
It may be the case that all you need is a responsive web site which can then be packaged for the required mobile platforms. This is a good first step onto the mobile landscape without incurring the costs of going full blown mobile. From here, you can then gauge how your app is received and decide what next steps to take (if any).
The key is to ensure you have a clear business strategy and that the mobile platform forms a cohesive part of that strategy. Going mobile just for the sake of it is not a strategy.
Going mobile needs to align with the overall business strategy to stand any chance of success.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
Well I'm currently working my notice with my current employer and start my new career next month. I'll be building responsive web sites and hybrid mobile apps using tools including Bootstrap, Telerik Platform and Cordova. These are technologies which I am not familiar with so I'll have to get learning. I'm at least familiar with web technologies (HTML5, CSS3 and Javascript) so this at least gives me a headstart on building web enabled pages.
Having previously used Xamarin.Android to build cross-platform mobile apps, it will be interesting to see the differences in building, testing and deploying hybrid mobile apps.
Should be fun. Exciting times ahead
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
|
Hmmmm maybe I ought to post this in the Lounge lol
Great article, I've bookmarked it so I can read it later
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
In this article[^] the author discusses the relative pros and cons of hiring someone who has attended a bootcamp (a short but intensive course) versus a college graduate. Like everything in life, neither is simply better than the other as it depends on what you are looking for.
First off, neither is likely to have much (if any) real-world industry experience, so on that basis they are evenly matched. If you are looking for a solid programmer, and are not necessarily looking for them to rise up the career ladder into more technical positions, then a bootcamper would be an ideal choice. If however, you are looking for someone with a greater depth of skills (particularly theoretical skills) who will contribute more in the future, then a college graduate is an ideal choice.
What the bootcamper may lack in theoretical knowledge they make up for in practical knowledge.
The choice between the bootcamper and the college graduate depends on what you are looking for. It would be unfair to say that one is better than the other as that simply wouldn't be true. As usual, context is important.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
I was recently reading this Why I Hate Best Practices -- Visual Studio Magazine[^] and it struck me that the title was mis-leading. In the article, the author makes the case that best practices are general rules and principles that have been demonstrated to work in practice, but that they shouldn't be rigidly followed.
This is a fair and reasonable point (although the example he gives to justify his point is not particularly well thought out). A best practice is just that. It's guidance only, not a rule. For certain specific problems, implementing the best practice may not be appropriate. Blindly following best practices can sometimes be counter-productive.
So whilst it's important to know when and where to use a particular best practice, it's also important to know when not to use a best practice.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
I'm sure we've all seen the job adverts for "rock star developer" or "programmer ninja". I'm sure (hope?) like most of my peers, we've sighed with exasperation as such silly, ego fuelled job titles. Thankfully this article[^] instils some much needed sanity on such job titles.
I particulaly liked this quote.
Quote: I’m more akin to a librarian, scientist, artist, and carpenter.
Couldn't have put it better myself. He sums up perfectly the blend of skills needed to be a good software developer.
As a professional software developer, I completely divorce myself from such job titles. I take what I do seriously and carry out my work with due diligence and pride. What I don't do is give myself overblown job titles which do absolutely nothing to enhance my reputation or my profession. Can you imagine seeing an advert for a "rock star airline pilot" or "ninja brain surgeon"? These sorts of titles do our industry no favours whatsoever. How can we be taken seriously when we have adverts for facile roles such as these?
Do you really want a "rock star developer" designing the security component of your enterprise application? Or heading up the implementation of your safety-critical flight navigation system? Or near your business critical on-line payment system? Hell no! These are roles where you want a safe and experienced pair of hands. People who have spent years in the trenches and got their hands dirty sorting out complex programming problems, designing software that works in the real-world, keeping screaming customers happy (or trying their best anyway).
Let's be honest, software developers love doing what we do anyway. We're a passionate lot and enjoy developing software for its own sake. We're geeks. We don't need to be enticed and seduced by silly job titles. And to those that are, stay clear of them. They're more concerned with stoking their egos than doing great work.
A personal plea to any recruiters or head-hunters who may be reading this. Please stop using these job titles. They're silly, unnecessary and trivialise the work that we do.
Our industry doesn't need "rock star programmers" or "programmer ninjas". Seriously, if this is how you see yourself, then please find another career. Our industry doesn't need you. It needs people who are dedicated, passionate, hard-working and take their work seriously.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
I think back in the day, everyone was just a "programmer", and that was good, and that was fine. Now, everyone wants to be a comic book hero.
Great post. 
|
|
|
|
|
When I got my first job as a junior programmer all those years ago, all I wanted to be was a good software developer. To get better at what I did, get better design skills, coding skills, debugging skills etc. And as you say, that was good enough. I'm actually perplexed as to where this new found desire to be a "rock star programmer" has come from, and why.
Thanks for the positive feedback
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
I recently read the following article[^] with interest. If you are asked a question in an interview and give an unexpected (but correct) answer, should this be seen as a positive or a negative?
In the article, the interviewer seems to mark the candidate down for giving an answer that is different to the one they expected. Whilst I accept that the expected answer in this particular case may be the one that conforms to better design practices and use of the language, the answer nonetheless still solves the problem, and this surely is the point.
The candidate is asked to solve a problem, for which there is no seemingly straight-forward solution. The candidate therefore proposes an alternative solution. In software, you cannot always just re-design the software to implement a new feature. Having the time will also likely be a luxury you don't have. Sometimes, just sometimes, to get the ball past the post, you need to take a different approach, however unpalatable that approach may be.
As long as the candidate made it abundantly clear that whilst the approach they have described is a quick fix and not the preferred approach (and would probably require technical debt at a later date), then giving an unorthodox answer shows both creativity and a deeper understanding of the language than the candidate who simply says it cannot be done.
I would prefer the candidate who solves problems than those who don't.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
Dominic Burford wrote: I would prefer the candidate who solves problems than those who don't.
and so does Google.
It has been my experience that open minded and flexible hiring practices, end up being a win-win for everyone involved.
|
|
|
|
|
It's that time of year again, when the Stack Overflow Developer Survey 2016 Results[^] are revealed.
It's no surprise to see Javascript as the most popular technology, with the rise of frameworks such as as React.js and Node.js.
I'd love to know who those developers are who self identify as "rockstars" and "ninjas". Even if you recognised that you were a good developer and better than most of your peers, would you seriously identify as one of these types? I think some egos need bringing down. However, it's reassuring that most developers self identify themselves as "developers". Phew.
The industry is still very heavily dominated by men with over 92%. I feel this is a serious issue that needs to be addressed. We need to get more women into our industry. It would be far better for it. That said, women do occupy creative roles such as designers which is encouraging.
Check out the article (linked above) in full and see what think. Feel free to leave a comment.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
After looking at the survey results a few times, I have to question its accuracy, really.
Also, what's a "growth hacker"? I'm going to have to look that one up.
Everyone I have ever talked to, hates Javascript, yet it is the most popular technology. I know the younger generation uses Javascript more than the older generation, based on my personal experience. I also know that the younger generation can't debug 5 lines of code to save their life, either - again, based on my personal experience.
I don't work with Javascript much, but I have been told, that it is very difficult to debug javascript well. If this is true, then it would explain why the younger generation like Javascript, because they sure as hell don't like debugging.
Interesting. All of it. Very interesting, indeed.
|
|
|
|
|
I too wondered what a "growth hacker" was. Not sure I like the idea of the word "hacker" being used anywhere near our industry as it has very negative connotations.
In my personal experience, javascript is used equally by younger and older generations alike. As it's the language of the web, we don't have a choice in the matter. If you develop software for the web, then you'll need to use javascript.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
I was reading an article recently written by a software developer on how he remained creative and focussed. He outlined several techniques he used to allow him to stay creative so that he could be more productive. Apart from being an inherently logical endeavour, software development is also a creative process. Coming up with solutions to solve problems with limited resources and often a rigid set of tools and within tight deadlines and fixed budgets necessitates a high level of creativity.
This got me thinking along similar lines. So here's a list of techniques I use to stay creative and focused.
1. Take a lunchtime walk at the office. This helps clear the head and allows a little downtime too. If you find yourself scratching your head trying to solve a problem, then often a simple walk will clear the head and allow you to re-focus when you get back.
2. Spend time with nature. Yes this may well sound very hippyish, but it's important to spend time in the natural environment. This can be during work or outside of work. Go for a stroll, a run, a bike ride or whatever.......but do it alongside Mother Nature. A stroll to the shops along a busy road is okay, but you really need to be exposed to the natural environment to really get the full benefit. Trees, birds, plants, cows in the field.....you get the idea.
3. Do something creative. Draw a picture, write a poem, write a story, anything that gets the creative juices flowing. You don't have to be any good at these things, that's not the point. The point is to spend time doing an activity that is creative. This in itself opens different pathways in the brain that you can channel to powerful effect.
If you have your own techniques for staying creative and / or focussed, I'd be keen to hear them
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
I came across this article recently Let's stop talking about quality[^] and found it really interesting. Whilst I can see exactly where the author is coming from, that different people tend to focus on different aspects of quality (usability, number of defects, code quality). Taken this way, quality is clearly an abstract concept where there will be little in the way of common ground between these different people.
However, if all of these factors are documented from the very begining and are part of the requirements specification, then this should prevent such discussions from arising in the first place. If everyone's definition of quality is taken into consideration from the outset (and of course there will be trade-offs and compromises) then this at least addresses the concerns that someone's definition of quality is not being met.
Whilst you can't keep everyone happy all the time, by at least considering their concerns and agreeing sensible compromises for how they can be met, this should ensure that a higher degree of satisfaction amongst the team is reaslised.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
I was reading an article recently that was comparing different programming languages, and it got me thinking about what criteria should we expect in every programming language. There seems to be an upturn in the number of new programming languages, from the mainstream to the obscure. Every week it seems that a new programming language is getting released. So what qualities should we expect in a programming language. Here's my list of qualities.
- A programming language must be predictable. Fundamentally a computer program is an expression of an idea written in a language that can be understood by a computer. It’s a medium for expressing human ideas and having a computer execute them, so it’s critical that a human’s understanding of a program actually be correct.
- A language must be consistent. Similar things should look similar, different things different. Knowing part of the language should aid in learning and understanding the rest. This sounds obvious, but it cannot be understated just how important consistency is in aiding the development of sophisticated programs using a particular programming language. It should also be consistent in how it implements a particular programming paradigm. For example, if the language is object-oriented or functional, then it should be consistent with that particular paradigm, such that a programmer with experience with the paradigm can learn the language with reference to previous knowledge and / or experience of the paradigm.
- A language must be concise. Or to put this another way, a programming language should NOT be verbose. If it takes numerous lines of code just to output "Hello world" to the standard output device, then it can hardly be described as concise. New languages exist to reduce the boilerplate inherent in old languages. (We could after all write machine code. Whilst this would be extremely concise, it would be incomprehensible to a human being). A language must therefore strive to avoid introducing new boilerplate of its own.
- A language must be reliable. A programming language is a tool used to solve problems, it should not create more problems of its own. They should minimise any new problems they introduce. Any “gotchas” are massive distractions.
- A language must be debuggable. When something goes wrong, the programmer has to fix it, and we need all the help we can get with this. The programming language should provide useful error messages, stack traces etc to enable the programmer to debug and fix the problem with the code.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
I think C# is a good programming language.
I think that for a new language to stand the test of time, it needs to provide something that "we" can't live without.
|
|
|
|
|
I think C# is a very well designed and implemented language.
Even a bad language can stand the test of time if there is little competition from other languages. To this list I would add PHP. An absolute monstrosity of a language, but gained widespread traction and adoption as there were few web languages around at the time. If PHP was invented today, nobody would use it.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
I was recently tasked with the problem of preventing users from clicking a button multiple times. This was on a login form whereby if the form was taking longer than normal, the user would click again....and again repeatedly. Whilst there was no impact on the product as such and no exception was thrown, it did register the fact the same user was logged in multiple times within the product.
There are times however when a user clicking repeatedly on a button can have far more adverse affects, such as posting a transaction or an update more than once, leading to inconsistent data.
There are several ways of solving this problem, but this one seems the most straight forward and simple to implement.
Firstly, you will need to add a fake button to your page. This fake button is what the user will see on the page. The original button will be hidden. The user clicks on the fake button. The text on the fake button is changed to indicate that the button has responded, and the button is immediately disabled.
To achieve this behaviour firstly add a fake button to your form as in the following example.
<%----%>
<asp:Button ID="login" runat="server" OnClick="Go" />
<%----%>
<input type="button" id="visibleLoginButton" value="Login" onclick="DisableButton(this)">
Now you need to add some Javascript to the page that will update the text on your fake button, disable it (so it won't get clicked repeatedly) and invoke the click event of your original button.
<script type="text/javascript">
function DisableButton(b) {
b.disabled = true;
b.value = 'Submitting';
b.onclick = document.getElementById('login').click();
}
</script>
Finally you need to hide your original button. Most people would naturally set visibility to false, but this won't work. The reason is that the form will only post back elements that are on the form. An element that has visibility set to false wil not get posted because it is not contained on the form. The trick is to set the display to none. This should be done in your form's Page_Init() event.
this.login.Attributes.Add("style", "display: none;");
And that's all there is to it. Happy coding.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
I came across this article[^] and found it quite interesting. As usual with these sorts of articles, some of the items you will agree with, others not so much.
Missing from the list (in my opinion) is a greater emphasis on cross-development tooling for mobile. These are development tools that allow you to target multiple mobile platforms e.g. iOS and Android. I have previously used Xamarin[^] but there are others, and with new tools being developed. I predict that in 2016 there will be new and improved tools for those wishing to develop apps for multiple mobile platforms.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
We often hear software developers talking about "clean code", but what exactly does it mean? How can code be clean? Presumably you don't take your code to the shower for a wash, so how can code be said to be clean?
There are a great number of articles and blogs on this subject, and there is even a book on the subject, so clean code is obviously an important topic in the world of software development. During interviews it is something that I try to look for (by asking the candidate to write some code, by checking their on-line source code repositories e.g. Github etc).
There is no single definition of the term, as it encompasses many different elements, and there will also likely be disagreement and discussion as to its definition amongst software developers. This list is therefore my own definition. If you have any comments please feel free to leave a comment below.
Clean code should adhere to the following constraints:
- Variables, functions, events and properties should have meaningful names so that their intention is unambiguous and obvious e.g. calling a variable x or y is not allowed.
- Proper use of comments. I know that this single statement will have opened up a can of worms by itself (software developers do love their religious wars) but what that means is to leave comments where they clarify and add useful information to aid in the understanding of a piece of code. How you define that is up to you (but please do so consistently).
- Low coupling and high cohesion. I won't explain what these are, as I am assuming that the reader already has an understanding of software development principles. All functions within an application should be independent and not rely on any global state. All dependencies should be passed via parameters and they should perform one and only one task, and perform that task well.
- Clean code is simple and well engineered as opposed to complicated and over-engineered. Whilst it is great to understand design patterns, object mappers etc. you probably wouldn't use them in a simple console app for importing your payroll data. Understanding good design is important, but of greater importance is knowing "when" to use them. Cluttering a very simple application with design patterns, object mappers and the like just makes the whole thing difficult to comprehend.
- Good levels of re-factoring. If you see the same code repeated all over the place then it is clearly breaking the DRY principle (Don't Repeat Yourself). If you find yourself writing the same code more than twice (although some would keep this at one) then you need to refactor the code into a function and call that function instead.
- Another developer should be able to quickly (relatively speaking) understand what the code is doing and make modifications. If the code is so incomprensible that it takes your average developer an increasingly long time to make sense of the code, then clearly the code is not intuitive. In the same way that we strive to make our user-interfaces as intuitive and self evident as possible, so we ought to strive to reach the same ideals with our code.
Writing good code takes practice and skill. It takes effort and attention to detail. This final quote from Michael Feathers best sums up the definition of clean code.
Quote: Clean code is a code that is written by someone who cares.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
