Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
iOS Good And Bad Programming Habits
- Thread starter Will0827
- Start date
- Sort by reaction score
There are some good books on this topic. One is Clean Code. It's fairly language agnostic and keeping code in good order is something you'll really want to do even on small projects. It's a good habit to form.
As an Amazon Associate, MacRumors earns a commission from qualifying purchases made through links in this post.
In object-oriented programming, classes, objects, properties, and variables are nouns.
Methods and functions are verbs, sometimes with nouns or adjectives.
You tell a <noun> to <act>. The <noun> is an object. The <act> is the action embodied in a method.
Specific to Objective-C and Cocoa, it seems a lot of novices (and some experienced) programmers have no idea of the naming conventions.
https://developer.apple.com/library...eptual/CodingGuidelines/CodingGuidelines.html
They name variables starting with upper-case letters, like MyVariable. This Makes It More Difficult To Distinguish One Thing From Another Because Every Single Thing Has The Same Emphasis As Every Other Thing.
They also name classes starting with lower-case letters, or with verbs, or with the word "Class" in them, like drawClass. This results in a different kind of confusion, where there's no clear distinction between things and actions. Two classic examples in English:
Buffalo buffalo Buffalo buffalo buffalo buffalo Buffalo buffalo.
That that is is that that is not is not is that it it is.
Methods and functions are verbs, sometimes with nouns or adjectives.
You tell a <noun> to <act>. The <noun> is an object. The <act> is the action embodied in a method.
Specific to Objective-C and Cocoa, it seems a lot of novices (and some experienced) programmers have no idea of the naming conventions.
https://developer.apple.com/library...eptual/CodingGuidelines/CodingGuidelines.html
They name variables starting with upper-case letters, like MyVariable. This Makes It More Difficult To Distinguish One Thing From Another Because Every Single Thing Has The Same Emphasis As Every Other Thing.
They also name classes starting with lower-case letters, or with verbs, or with the word "Class" in them, like drawClass. This results in a different kind of confusion, where there's no clear distinction between things and actions. Two classic examples in English:
Buffalo buffalo Buffalo buffalo buffalo buffalo Buffalo buffalo.
That that is is that that is not is not is that it it is.
This book is AMAZING!!!! Love Uncle BOB! The first two chapters should be required reading for all tech and tech related employees.
"Comments LIE!"
As an Amazon Associate, MacRumors earns a commission from qualifying purchases made through links in this post.
I would strongly disagree here. Uncle Bob has a way of splitting down methods into too small methods each which does almost nothing. All he achieves is essentially the creation of a new language. If you are looking to stay employed this is a great way to keep yourself occupied but if you take over a project written this way you will want to stab the author with a blunt instrument.
In some circles Uncle Bob is hailed like the new messiah. To me he looks like the poster child of all the projects that were never completed.
Avoid like the plague.
As an Amazon Associate, MacRumors earns a commission from qualifying purchases made through links in this post.
He creates a new language? I didn't gather that from the book.
What is the issue with small methods? Almost all of my methods fall into the 20 lines or fewer category.
Yes I have. No I have not watched any videos. You don't have to agree with the book (I don't agree with it 100% either but that goes for most CS books), but there is a fair amount of useful information in the book.
The book appears to be well written to sell books and seminars.
The proof is not in any chapters or videos, but in whether successful programmers or companies actually keep using the described methods and succeed. Some do. But many dump them after an initial try as actually reducing overall productivity. e.g. they clean up messes that are in the opposite direction, but when taken seriously make another kind of mess.
I would hate to read a developers code who created over complicated functions that no one could read and took ages to understand because they were doing 27 things that take way too much time to reason about and create awkward dependencies in the system which make the system very hard and painful to change. Sure get your app/feature fixed first but then you can go back and refactor it so you aren't creating tech debt that others have to manage later.
----------
That's true of most good or great developers.
----------
I disagree here. I've worked for several well regarded companies in the tech world that subscribe to his teachings. I've worked at companies that wish they had initially because now getting a feature released that should take roughly a weekend ends up taking months.
Last edited:
Overall it's good to read multiple and differing opinions on programming habits. Don't just read the "You should do it this way" part, also read the "You should do it this way because" part. Depending on your situation various habits make better sense. For my stuff at work, unit tests make a lot of sense. I really have no say in the customer requirements. So when marketing decides to change something, I have to change it. Having a set of strong unit tests is essential so when I make the changes I can ensure myself I haven't broken anything. For others this might not make sense and that's fine. I've historically found more benefit to having them than not in my area. Likewise with code. Some prefer to write super tiny code with extreme efficiency. Some have no idea what they are doing and copy paste until it works. I prefer a middle ground that is concise but you can easily determine what it is doing.
The more you read about programming habits, the more you'll change to what suits your needs and that's a good thing. Just don't ever say "I'm doing it this way because 'source X' said so". Instead be able to say "because of these benefits". Also don't be averse to changing if somebody makes a solid argument that the benefits you're getting are better gotten another way or are even not really benefits.
The more you read about programming habits, the more you'll change to what suits your needs and that's a good thing. Just don't ever say "I'm doing it this way because 'source X' said so". Instead be able to say "because of these benefits". Also don't be averse to changing if somebody makes a solid argument that the benefits you're getting are better gotten another way or are even not really benefits.
Yeah, thats a good one.
I dont want to be too much of a Rails advocate, or DHH fanboy, but theres certainly many good habits baked into the design ideas of the framework (and the Ruby language for that matter), and in many of the programming conventions and patterns heavily emphasized in Rails: MVC, DRY and even some of the common-to-Rails management practices like Agile.
Of course, YMMV, and I tend to pick and choose parts of methodologies that are effective to me, as I have to see an end-to-end strategy thats wholly effective.
Fun thread.
I like the video because it kindof points out that;
If you write **** code, your code is **** no matter what design philosophy you use. A philosophy (or ideology) alone is not going to fix your code.
I think this is often overlooked, just like a fad diet.
Of course I have unit tests! But only where I think I will benefit from having a test. Don't confuse unit tests with TDD.
I had the great fortune of working with a contractor for a while. The fella oozed experience, he'd been coding since before I was born! His take on it was pretty simple.
Write your code as if the next person is a deranged serial killer and he has your address.
If you write **** code, your code is **** no matter what design philosophy you use. A philosophy (or ideology) alone is not going to fix your code.
I think this is often overlooked, just like a fad diet.
Of course I have unit tests! But only where I think I will benefit from having a test. Don't confuse unit tests with TDD.
I had the great fortune of working with a contractor for a while. The fella oozed experience, he'd been coding since before I was born! His take on it was pretty simple.
Write your code as if the next person is a deranged serial killer and he has your address.
I don't care for TDD either. I tend to write unit tests based on my documentation (if my documentation says my code will do X, it better do it!) and sometimes I update my documentation based on my unit tests.
Definitely. A good methodology doesn’t make bad code good, it makes good code even better
I’ve had to do a few code pickups over my career (~25 years), and I’ve seen some code that sent me into seizures (usually PHP, not because you can’t write decent PHP, but because there are a ton of “non-developers” hacking around in it...)
Admittedly, I’ve written some janky code too
Usually I had a “good” excuse, i.e., time constraints, starting with inherited code [see above], or even better, being tossed head first into a brand new language/framework, usually combined with a tight schedule. I look back at some of my ancient Java or Perl code and I assume lots of illegal narcotics were involved ...Hahaha, a few years ago I was helping with a project at a friend’s company, they said, “Oh yeah, it’s PHP”, I said “OK, no sweat” (even though I greatly dislike PHP and it could’ve been done using a framework I was unfamiliar with, Cake, Zend, whatever). So I finally get the source ... it’s Python/DJango, so yeah, learned that as I went (I was already reasonably familiar with Python in terms of system scripting, just not in a web DSL). I’m sure someone saw this code later and cursed my existence
re: the bold section
I’d just clarify for other folks reading this: Unit Test is more about what is tested, TDD (Test Driven Dev) is more about _when_ you test. i.e., your TDD would likely use Unit Tests.
Yeah, I’m not a fan either, and most of my private sector work is in Ruby/Rails, so that community tends to dig on that approach, but like you, I tests against docs/reqs.
Totally off topic: my little girl had a blast watching that panda live video feed
They were really active the last day or so! (she’s a big panda fan ... and unicorns, but I can’t find a live unicorn video feed ...)1 Not looking at the big picture. The over all structure is likely more importance than the details. Goods designs typically have fewer parts with less interconnections between the parts than bad designs. In other words bad designs tend to be more complex. It is worth spending twice as much time as you think you need getting this correct. You will get a huge payback later.
2 Along the lines of above. Failing to do a good high level design and jumping into coding to soon. I think this is because coding is all most beginners know.
3 Thinking that version control, bug tracking, good comments at the top of every functional block and file all don't apply to them.
4. reinventing to many wheels. Many beginners maybe can't understand some big library/API so they think it is easier to re-implement the functions they need. But then they have created a huge maintenance problem and their reinvention will never be as mature and well tested. I've seen people pushing data to port 25 because they thought the system sendmail interface was to hard to use and others writing an entire files management system because they thought SQL was to complex to learn.
I can't believe how many times I've seen all of the above
I agree with bug tracking and version control. However your statement about comments I am going to disagree with partially. When I go through them they almost never add anything of value and in almost all cases they confuse more than help me to understand what is going on with the code I'm looking at. They aren't updated regularly and almost never are. You don't need to comment on every function in a file. That's nuts and bloat that isn't always needed...and they almost never are updated properly because everyone is afraid to change them in practice even when they are wrong. In short comments LIE.
I tend to think there is an over reliance on comments because someone wrote terrible code that even they can barely understand. From my experience if your code is good enough and clear enough it should be self documenting. I should be able to look at your code and figure out exactly what is going on otherwise you need to rethink what you are doing and how you are doing it in most cases. I can't even begin to tell you how many times comments lead me down the wrong path or just confused me. I shouldn't have to go back to the original devs and ask them what their comments mean.
In theory, it sounds like a good idea to comment every function or every file yada yada... In reality and in practice, its not necessary and comments do more harm than good. I believe people should use them sparingly.
I think many comments are crap because they're commenting on the wrong thing: they comment on the What, rather than the Why.
I don't need comments to tell me that a sum is being calculated in a loop. I can read the code and see that. What I want the comment to tell me is why the sum being calculated in the loop matters.
One part of Why is the rationale: the explanation of why this algorithm was chosen, or why an algorithm was changed slightly from the obvious one. So if there's something unusual in the midst of the code, don't just tell me it's unusual, tell me why it needed to be unusual.
I also find that some comments will attempt to explain a well-known algorithm, and do so badly. If the algorithm is known, simply refer to it in a well-known book or reference, such as Knuth, or Sedgwick's "Algorithms". These days, giving a Wikipedia link or keywords is probably a good proxy, because so many common algorithms (and a fair number of uncommon ones) are well described online.
You're very confused. Comments say what the author thinks the code does (or should) do and/or why they wrote it. They may not actually say what the code actually does.
No, see, you're the problem. You think you don't need comments. Please stay away from me and any projects I work on.
"Self documenting code" can "lie" as you put it. Just because I gave my function a name that says exactly what the function should do doesn't mean it actually does what it should do.
Which is why you write unit tests - good unit tests that actually verify your comments and variable names, at that.
----------
You can take this either way too far. There's a lot of poorly written, stupidly complex libraries that just shouldn't exist. If you're reducing 50 lines that took you a full day to write down to 5 lines that took you a full week to write because you needed to learn the ins and outs of a complex library you'll never use again, you're probably better off with the 50 lines.
Further, try to make those 50 lines into a nice, focused, but complete and reusable library, and publish it. Don't forget to make some documents and show example code using it.
As an example of a library not worth using at all: RestKit. It's fantastically complicated and gets you next to nothing. I would have gone through the effort of making a nice, focused library like I mentioned, except someone already went through that effort and made MKNetworkKit, so I just use that (4 small files vs 20 huge files - a few minutes to learn vs a few days to learn).
At the same time, obviously reinventing SQL is silly. It's surprisingly simple to use given how complex it is underneath. You won't be reinventing it and getting better results if you don't even understand how it works.
I do not recall saying comments are never needed. You took what I said and changed the meaning of what was actually written. Are you trying to help me illustrate my point about comments for me? LOL!
I think comments should be used sparingly. Do you really think comments are always needed? Write better code rely less on comments. When I see a comment I'm like ok I know some crap code is coming up that needs a refactoring or two. That is usually the case. Again I do what the team has agreed to do. If they say comments is what we do. I write comments. However, that doesn't mean I agree with the logic behind blanketing code with comments. I don't subscribe to all or nothing approach to comments. I'm very much in the gray, use as needed, camp as it relates to comments.
You tried to dumb down my argument to function naming because I pointed out the over reliance on comments from sucky programmers in the industry who can't reason about code unless its "commented". I mean really? That's not fair at all.
I believe documentation is absolutely necessary to explain the how and whys. That is separate from commenting every function just because. Saying you don't need all of the comments that are put into code in reality is quite a bit different from saying you never need comments. I said the former. You tried to turn that into the latter. Write better code. Rely on code to convey meaning. Use comments only when needed.
The truth is in the code NOT in the comments.
.....
As a separate matter, I find that unit tests make code easier for me to change. It can seem like a pain when you are writing your tests but they grease the wheels significantly when you need to add new features or fix bugs. Tests can also have a documenting effect to them when done correctly.
Last edited:
You write comments to describe why you are doing something not how. No amount of refactoring is going to describe why you chose a given algorithm or why you chose to perform a given task in a certain way.
Remember you don't comment code to describe what the code does. You comment code to describe why the code does what it does.
It sounds to me like you don't know how to comment code effectively or haven't worked on code that uses comments effectively. I can always read the code to see what it does but no amount of reading the code tells me why it was done the way it was.
I find it much more important to comment my methods than the interior lines of code. On rare occasion I'll comment a bit of interior code but not too often.
A coworker I had a long time ago commented nearly every line of code and it was maddening. I kid you not, above an i++ statement they had commented:
I didn't feel good enough yet in my skills to thwap them over the head but these days I would have had a sit down with them.
A coworker I had a long time ago commented nearly every line of code and it was maddening. I kid you not, above an i++ statement they had commented:
Code:
// increases the value of i by 1
i++;I didn't feel good enough yet in my skills to thwap them over the head but these days I would have had a sit down with them.