Just wondering, it seems like it works pretty well but I want to make sure I am using generally accepted coding practices and not get into bad habits.
Thanks,
Nick
Yes, it's good form. It was introduced as the preferred style of enumeration in Objective-C 2.0, in fact. Use it wherever possible.
Fast enumeration is a recent addition to the language, so don't be concerned that you're not seeing it much in other people's code. It takes a while for people to adopt new habits.
Related
If I had a variable day, and I wanted to distinguish it from a class Day or something, I would probably write getday instead of getDay. Is this good practice or is there some better alternative?
Normally when we code according to the coding conversions, It's not a good practice. Use getDay format. Its measure your best practice and skill level of proper coding :)
This is kinda opinion based, but getday is a little harder to read than getDay. The second one is just much cleaner and you can see from the first sight what that metod is about. So I'd go with getDay
While reading "Python scripting for computational science" I came across the following text in the section discussing generators:
Whether to rapidly write a generator or to implement the class methods __iter__ and __next__ depends on the application, personal tast, readibility, and complexity of the iterator. Since generators are very compact and unfamiliar to most programmers, the code often becomes less readable than a corresponding version using __iter__ and __next__.
This led me to wonder whether unfamiliarity (of other programmers) is a good reason NOT to use relatively new and powerful features of a language (like Python generators).
If you don't use it, how can it ever become popular and familiar?
So, my question: is unfamiliarity sometimes a good reason not to use new language features?
Your own unfamiliarity with a language feature may be a good reason to tread lightly. For example, in C#, if you aren't certain about the differences between object y = func1() ?? func2(); and object y = func1() != null ? func1() : func2(); (hint: left-to-right order of evaluation), then maybe you are better off writing the corresponding if clause just because it's clearer what actually is going on. Someone who knows the nuances of the language better may very well come around and refactor later, and in the meantime, the cost is usually low.
However, if you know how to use a language feature, I see little reason to avoid using it simply because others may find it difficult to understand. If you really feel the need to, then add a comment (such as, perhaps, "?? is the _null coalescing operator_") to help fellow developers know what to look for if they can't figure out from the code alone what it is doing, and you are afraid that they may have to go it alone.
This, mind you, is about production code. Experimenting certainly has its place, but its place is not necessarily in the mainline codebase. I always keep a "scratch" project handy for when I want to try something out without risking impact to anything else. There, I often take liberties far beyond those I take in production or to-be-production code.
I wouldn't say that unfamilarity is a good reason to not use new language features. Or for that matter, use new languages.
Lack of support for a new feature across tool vendors could be a reason if you have any concerns about working with multiple vendors.
Since the question is subjective, I'll express the contrary opinion.
If you work where there are code reviews, you'll find out soon enough what your co-workers consider "unfamiliar".
Since they also have to maintain the code, you can try and help them become familiar with the "unfamiliar" code. But, it's ultimately a judgment call, and sometimes, what you think is clear code, isn't.
One of the books that I reference rejects dot-notation for properties in Objective-C 2.0. Is this a common mindset?
Note: This is an empirical, programming-related question regarding the popularity of a syntactic tendency. Obviously, the most useless answers are personal -- "Well, I don't use it," -- and the more interesting ones come from a larger universe of observations. If anybody has any actual statistics on the matter, that's even better.
If you look at the code people post on Stack Overflow and Apple's sample code, you'll see that dot notation is very commonly used. Some people prefer the normal message-sending syntax for philosophical reasons, but it's generally taught with dot-notation these days, so it's not unreasonable to assume that's what most people use.
The most popular and prominent example of "anti-dot" sentiment is Joe Conway's post on the Big Nerd Ranch blog. The Big Nerd Ranch guys are very venerable Cocoa programmers, so people tend to take their opinions seriously.
No, it's not a common mindset. If you look at the sample code people posted here, you'll see that the majority of people are using it.
My personal opinion is that it was a mistake to invent it. It confuses beginners into thinking that property access is somehow different from normal message passing. Having said that, there are occasions where it makes code clearer to read.
I don't use it, because it only works if I define the type of the object. Often, my objects are of type id, and that doesn't allow me to use the dot syntax. So, because I don't want to have to bother to check what kind of type I declared my object as, I just don't use it.
I'm currently working on a site which went through god knows how many developers' hands. One of the things I don't like about it is the way every table in the database has the prefix "tbl_" and every field "fld_".
I've started work on a new feature and I'm faced with the following problem: should my new tables continue with the old convention, or not?
I guess I should, but I feel stupid doing it :)
I would keep the same convention.. Regardless of if it's bad or not at least it would be consistent. And consistency will be very important to the next developer who gets ahold of the code.
Being a contractor, I am faced with this problem a lot. Here is my 2 cents:
If it isn't broken, then the client is wasting their money having me change that. Unless I am rewriting the entire app, I usually keep with the old (bad) standards (at least that way, you don't have part of the app with one convention and other parts using something different - this keeps the code readable by other developers).
You have two options.
Change all the bad naming conventions to new ones.
Use the old conventions.
Someone will be looking at this code later and will need to deal with any differences you create. That means you need to be aware that other people are affected by this decision. Do the right thing if you have time, do the ugly thing if you don't have the time... but keep it consistant.
If it a constant style throughout the application I would follow the naming convention it will make it much easier on the next developer.
I tend to look at the scale involved. The consistency of a bad naming convention, to me, is preferable over a multitude of different ones in the same codebase or database.
If there are a handful of tables and you can safely change them, my feeling is to make the change. But anything of scale or an application that you're only doing a bugfix on is likely not worth the time and effort involved.
Go with which ever route costs less, in money and resources. If it's not going to save you money going through and re-tilling the ground, then don't. Just grit your teeth and move forward.
"If it ain't broke, don't fix it"
I think you should prefer consistency and follow the convention already being used.
Think of the poor developer(s) who come along behind you and have to deal with two different naming conventions (the original one and your new one), neither of which the new developers like.
Welcome to the world of maintenance. ;)
Who's to say that the next person who works on the site won't despise the way you did things?
Any naming convention is better than no/inconsistent naming convention.
I say change it iff there's a significant difference between the old code and the new code. For example, if the old way was a terribly dead-end and the new way is completely independent, then go ahead and start a new convention.
It's good to be visually consistent if the new material is structurally and semantically consistent, but if what you're doing is a clean break from what came before, then it's even more important that different things look different.
Like everyone said, stay with the bad convention since you are not writing it from scratch. However, use "good practice" if there is a compelling need for it (aka the end-user will be negatively affected otherwise). For example, if the "bad convention" makes the API users use boxing, change the value of strings and other performance-hit to a great degree; do not add to the problem! The end goal of software and API's is not to make the developers' life easier; but the end-user's. Developers that stay in the business long are highly aware of this and you want to be one of those developers.
I'm looking for some good courses on object oriented programming. I've been programming for about 4 years so far, but I don't feel like I have a SOLID grasp on OO.
How did you learn?
Its all learning by doing. Courses and books are good, but the bottom line: Coding is all about writing programs; start from there. Another thing I personally think is very important: read other peoples code!
Try these: http://webcast.berkeley.edu/course_details_new.php?seriesid=2008-D-26263&semesterid=2008-D
Maybe you'll like the "Head First" approach.
The mechanics of OO (i.e. the syntax and semantics, terminology, what it is, what it does) are very easy. They "why" and "where" of it is the hard part. I'd suggest you just learn the mechanics quick and dirty on Wikipedia if you haven't already, and then pick up a book on design patterns. Head First is a good choice here. I don't believe that you can truly understand OOP (or really anything for that matter) unless you know where it's useful and what problems it's meant to solve.
After this, the next step would be to look at APIs you use every day in your favorite language from your new perspective. You should start seeing why using OO techniques in certain situations makes the API much more usable than if everything were just free/static functions and plain old data objects. You might also see areas where OOP is awkward and overused and free/static functions and plain old data objects might be better solutions.
Lastly, it's useful to know how some aspects of OO are implemented at a lower level. Understanding things like virtual function tables and how to do OOP in pure C really adds a level of depth to your understanding of what can and cannot be accomplished with it, and what the tradeoffs are inherent in it.
And obviously, try to integrate what you learn into the code you write.
Since you ask :) I learned with Object Oriented Software Construction, 2nd Edition by Bertrand Meyer, Prentice Hall, 1997.
Meyer is due to publish in a very short while a book which is focused on learning to program from the start: Touch of Class. This should be a good option for students.
I notice that people's tastes about learning materials vary quite a lot. Some like summaries, tutorials, how-to's... I learn complex subjects by taking my time to follow the complete dissertations.
A pure-object language is the best course in OO.
I can suggest Java, Ruby, or Smalltalk
Learn any of those (from scratch, not just as rewriting C or Perl) and you know OO.
I would go with ruby, it's more mainstream than smalltalk, and has a richer syntax than java. Perfect for the beginner
It is REALLY difficult to learn this by yourself. The best chance is to learn it alongside someone else at your workspace, who's going to get you through tasks and shows you things on the way.
I can recommend this book. http://squeakbyexample.org/ it's far from perfect, but it's free and comes with a special squeak version that is optimized so you find the code fast. The examples are kind of nice for starters, I think. At least I enjoyed reading it.