Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
I do not want to ask candidates questions, but rather give them several problems to resolve. The reason for this is that I've seen people be excellent with theory, but when confronted by a real world c# issue, just couldn't hack it.
These c# problems should be simple enough that it won't take more than 1-20 minutes to resolve, yet complicated enough that I'd be able to weed out candidates that can't code.
Right now, I typically ask the applicants to reverse a string and remove duplicates from a List. This alone weeds out a large number of people.
Any other examples I could use?
Edit: I should have mentioned that this is for a standard c# gig, where they'll be writing business code rather than finding the most optimal way to implement a linked list.
I like picking simple problems that I actually had to solve at some point; it doesn't get more relevant to the job than that.
When I worked on VBScript I'd ask college candidates how to write a simplified version of DateDiff, since doing so was what I did my first real day of work at Microsoft. More advanced candidates I would ask how to build a device which tracks the relationship between 32 bit handles and an associated 64 bit pointer, which again I actually had to do when working on VBScript.
More recently I tend to ask questions about tree manipulation algorithms, since the compiler is all about tree manipulation. Or about how to codegen new operators using monads, since that's how LINQ works.
My point is not that you should use questions in these areas, my point is that surely you must have had problems that you had to solve in your day-to-day work. Ask the candidates about those problems -- then you'll learn how they solve a realistic problem, and they'll learn what sorts of problems they'd be solving if they came to work with you.
dont ask for knowledge of class libraries or obscure corners of the language (unsafe, dynamic, ..); smart people can pick these up or look them up.
I would ask to design a class hierarchy to represent something real world (vehicles, animals, ...). This usually flushes out the people who dont get objects. Make them do it with interfaces too. Also make them reverse a string - no harm in oldies but goldies
I agree with you, it is surprising how many people claim to be experienced and you find out that all that they did was read the box…
I don’t know if testing for C# is as valuable as it first seems… sure you could ask them to describe an example of when they needed to use inheritance, or why casting might have a performance problem, etc. But these are easy to study for. You would be surprised at how many interviewees give the example using “car” or “color” when giving their real world example of inheritance…. Guess they are in a book somewhere.
When looking at this problem it helps me when I compare experience in development to learning Spanish. A short time into the class everyone is conjugating verbs and can pass a test on this… but nobody speaks Spanish yet. You want the guy that claims to speak Spanish and can actually do it.
So I like to be more specific with the other technologies that will tell me if they have traveled the well-worn path of development. If they say they are an ASP.Net developer I ask them simple questions, but ones that are on the path
EXAMPLES: Give me an example of where the connection string could live? If you need to pass an ID from one page to another, what are your options? If a page takes 5 minutes to load, tell me how you would go about troubleshooting it. If I had a web page that had a single button on it, how would I center that button? Tell me the difference between storing variables in the viewstate verses session state?
You don’t have to know everything, but eighty percent of the people interviewing for a senior level position will get 10% of these types of questions right. (And on 70% of the phone interviews you will hear them Googling for the answers – good thing these aren’t the types of questions you can easily Google for.)
SQL Server is about the same. They say they would rate themselves an 8 or 9 in SQL Sever development, but then get 10% of questions. The questions again are to see if you have been on the well-worn path.
EXAMPLES: If you had a table of customers and a table of orders, how would you find the customers that had no orders? What is a clustered index? If I had a table of developers and a table of projects, how would I set it up so that projects could have multiple developers on it and developers could be on multiple projects?
How could you develop in SQL Server for “years” and not have hit these concepts? A high percentage of candidates get almost none of these answers right!! (I guess the SQL Server box isn’t as informative.)
So if you say you are a senior level guy and you can say “Soy un revelador de software” (I am a software developer), but can’t say “He hecho eso antes” (I have done that before), I don’t think you are the senior level person you are claiming to be.
Now this tells you if they have been on the well-worn path, but not if they are smart and have good problem solving skills. Having gone thru a ton of these types of interviews I can tell you that by the time the process is done you will be satisfied with having enough information to have a strong opinion on both of these issues. You might also see that by then giving them a problem set to solve is unnecessary.
Show them a small section of code or architecture diagram from one of your own projects and ask them to suggest how they would refactor it. Even if you don't wind up hiring them, you might get some interesting suggestions on ways to improve your code.
Building Eric's and other answers here, but answering as an only-ever-so-far-interviewee, what I would like in an interview is a kind of pair-programming 'test', where you sit down together facing the screen, and talk through a real-world problem.
I think there would be many advantages:
For the interviewee, being in front of a screen instead of facing the interviewer makes it easier to think about the problem rather than the interview.
For the interviewer, being with the interviewee while they look through the code and ask questions about the problem space would give a much greater insight into how the interviewee thinks, how they approach problems, and how they communicate and interact with others.
I would expect that it's more important and interesting to see a candidate thinking round the edges of your real-world problem, even if they don't completely solve it, than to have them get 10 out of 10 on come algorithmic test.
Something mildly algorithmic.
Write a method that returns true if a string is a palindrome, and false otherwise.
Re-implement the String.Substring(int, int) method.
Something about object-oriented design too.
Design a checkers game (ie, define the classes and some of the methods).
One question I was asked, and subsequently ask interviewees, is"Describe how you would make this phone into an application". Have them describe the classes, their properties, methods, interfaces, etc. Then question them on why they chose to implement them in that specific way. It gives you a good idea if they understand how to code, and gives you some insight into how they approach and solve problems.
Also, if you offer a suggestion of how they could have implemented it a different way, it may show you whether they are open to new ideas, criticism, or if they are a team player or not.
Fizz Buzz
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 9 years ago.
Improve this question
I've read some things about this, I even found similar question, but it didn't really answer this. For me it seems that privatizing something only makes my life so much harder when I need to find a private variable in a class to use it elsewhere. So what is would the problem be if everything was public? Would it somehow slow the program itself?
You must consider the maintainability of the code. Accessing all the variables everywhere in your solution is good only if you are the only one in the project and you will be the only one that maintain and use the code. If someone else's entered into project and do completely different things they will be able to access your methods/variables and set the things to unexpected variables. You should think as a OOP design and design your classes like that.
FYI I don't believe you are supposed to ask discussion-based questions like this on SO... But the simplistic answer is this: don't limit your thinking to the logic of the code. We all know there are ten thousand ways to accomplish the same thing. You can probably rewrite a bunch of your code to avoid encapsulation. However, data encapsulation provides a few benefits when you start working on larger projects or with larger teams that go beyond just writing functional code:
(1) organization by concept: if you're coding a bike you would code a class for the wheel, a class for the frame, a class for the handlebars, etc., and you'd know where to go to resolve an issue, perhaps even after months of time away from the code;
(2) separation of implementation and interface: you can tell the world about your public interface and handle the actual implementation privately, so people don't have to know how things work in your code, they just know that it works, like a black box; and if later you have to change your private implementation you can do so freely as long as the public interface still works;
(3) simplification for humans: remember, humans read your code, so would you like to slam them with every bit of data and logic in your project? that would just make for a bunch of angry programmers.
So that's a gentle introduction to encapsulation.
This comes from the fact that, a class should not expose its members directly but must provide a proxy through which the members must be accessed. (Like getters/setters or Properties)
See this question for more info: Why it is recommended to declare instance variables as private?
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
Before down-voting let me explain my question. I have a little experience in designing architectures and try to progress. Ones, when I was fixing a bug, I came up with a conclusion that we need to make our private method to be public and than use it. That was the fastest way to make my job done, and have a bug fixed. I went to my team-leader and said it. After I've got a grimace from him, I was explained that every public method is a very expensive pleasure. I was told that every public method should be supported throughout the lifetime of a project. And much more..
I was wondering. Indeed! Why it wasn't so clearly when I was looking in the code. It wasn't also so evidently when I designed my own architectures. I remember my thoughts about it:
Ahh, I will leave this method public, who knows, maybe it will come usefull when the system grows.
I was confused, and thought that I made scaleable systems, but in fact got tons of garbage in my interfaces.
My question:
How can you explain to yourself if a method is really important and worthy to be public? Are any counterexamples for checking it? How you get trained to make private/public choise without spending hours in astral?
I suggest you read up on YAGNI http://c2.com/cgi/wiki?YouArentGonnaNeedIt
You should write code to suit actual requirements because writing code to suit imagined requirements leads to bloated code which is harder to maintain.
My favourite quote
Perfection is achieved, not when there is nothing more to add, but
when there is nothing left to take away.
-- Antoine de Saint-Exupery French writer (1900 - 1944)
This question need a deep and thorough discussion on OOP design, but my simple answer is anything with public visibility can be used by other classes. Hence if you're not building method for others to use, do not make it public.
One pitfall of unecessarily making private method public is when other classes did use it, it makes it harder for you to refactor / change the method, you have to maintain the downstream (think if this happen to hundreds of classes)
But nevertheless maybe this discussion will never end. You should spend more time reading OOP design pattern books, it will give you heaps more idea
There are a few questions you can ask yourself about the domain in which the object exists:
Does this member (method, property, etc.) need to be accessed by other objects?
Do other objects have any business accessing this member?
Encapsulation is often referred to as "data hiding" or "hiding members" which I believe leads to a lot of confusion. Inexperienced developers would rightfully ask, "Why would I want to hide anything from the rest of my code? If it's there, I should be able to use it. It's my code after all."
And while I'm not really convinced with the way in which your team leader worded his response, he has a very good point. When you have too many connection points between your objects, you end up with too many connections. Objects become more and more tightly coupled and fuse into one big unsupportable mess.
Clearly and strictly maintaining a separation of concerns throughout the architecture can significantly help prevent this. When you design your objects, think in terms of what their public interfaces would look like. What kind of outwardly-visible attributes and functionality would they have? Anything which wouldn't reasonably be expected as part of that functionality shouldn't be public.
For example, consider an object called a Customer. You would reasonably expect some attributes which describe a Customer, such as:
Name
Address
Phone Number
List of orders processed
etc.
You might also expect some functionality available:
Process Payment
Hold all Orders
etc.
Suppose you also have some technical considerations within that Customer. For example, maybe the methods on the Customer object directly access the database via a class-level connection object. Should that connection object be public? Well, in the real world, a customer doesn't have a database connection associated with it. So, clearly, no it should not be public. It's an internal implementation concern which isn't part of the outwardly-visible interface for a Customer.
This is a pretty obvious example, of course, but illustrates the point. Whenever you expose a public member, you add to the outwardly-visible "contract" of functionality for that object. What if you need to replace that object with another one which satisfies the same contract? In the above example, suppose you wanted to create a version of the system which stores data in XML files instead of a database. If other objects outside of the Customer are using its public database connection, that's a problem. You'd have to change a lot more about the overall design than just the internal implementation of the Customer.
As a general rule it's usually best to prefer the strictest member visibilities first and open them up as needed. Combine that guideline with an approach of thinking of your objects in terms of what real-world entities they represent and what functionality would be visible on those entities and you should be able to determine the correct course of action for any given situation.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
Does anyone have any suggestions about how to estimate how long it would take to comment and reorganize the code of an entire project?
I just started doing contract work for a company along with another programmer: he's fixing bugs and I'm reorganizing the code. I'd like to make an estimate of how long it would take me to go through the code line-by-line and comment and/or reorganize the code is I go. It's a very large solution: it has two projects, each with multiple files.
It was suggested to me to count all the lines of code in each file, sum it all up, and double your hours to give you padding. It was also suggested that I square the size of the code before estimating. But I don't know how long it's supposed to take to comment, say, 100 lines of code.
Any suggestions would be more than welcome. If it makes a difference, the project is made in Windows Forms using Visual Studio 2012.
Thanks!
I suggest you pick a small random sample (20 lines) and try to reorganize it.
That would give you an idea of how long it takes (if you multiply), and it won't be underestimated, since the randomness of the sample will actually make the work slightly more complicated.
You can also do it two or three times, and see if the variance is small.
Any other method that is not based on you might be less expensive in time, but will not yield results that are tailored on you.
In my opinion this method is a good investment.
First, this is an estimate - estimates are not exact numbers, they are approximations and ranges. The estimate you have at the start may be wildly off once you start getting into it and the estimate would need to be refined. Take into consideration the code of uncertainty when giving an estimate.
There exist many well established models for software estimation. COCOMO II is one of these. I believe that this particular approach has added value to its techniques in that it can work from an already known amount.
A web tool for the COCOMO II can be found at usc. Count up the lines of code you have now. Make an approximation of how many lines of new comments you will need, how much will be able to be reused, and how much will need to be modified. Plug those numbers in. The definitions of how COCOMO II works and all the terms can be found in the usc ftp site
Lets say you have a 10k SLOC existing code of which 75% can be reused, 25% will need to be modified (75% design modification, 100% code modification, ...) and an additional 10% for commenting. There are arguments for and against tweaking the various cost drivers (changing things from 'Nominal' or leaving them as they are).
Plug this in and you get an equivalent size of 2825 SLOC which then translates to 9.2 person months of effort (remember, this isn't just going thorugh the code line by line - but also making sure you have the redesign correct and testing it). Nine months is approximately 1500 work hours.
Consider getting Software Estimation: Demystifying the Black Art which goes into more aspects of what an estimate is and other techniques to do an estimate (this is an estimate by proxy and just one of many techniques).
Remember to save the data on how long it took and your estimate - over time, historical data can help refine estimates.
Further reading on Wikipedia Cost estimation in software engineering
You might be able to find nasty bits by using some sort of code analysis that shows you the complexity of the classes.
Checking for code that is not covered by unit test will also help you to find code that is harder to refactor.
In terms of commenting the code, presumably that means reading every line and describing each method/interesting piece? Ignoring all the usual debate about this, firstly, you have my sympathy, and secondly, I would suggest picking a few classes, and doing the work, and measuring how long it takes: you should be able to extrapolate from there (and add 30% afterwards)
As to reorganising, unless you already know of certain specific large scale refactors you need, my usual answer to "how long will it take" is "how much better do you want it to be?" - and the final answer, always, ends up being a time-boxed amount that is agreeable to both you, and the boss/client. Make a suggestion of x days, and do as much good as you can in that time. Also, someone mentioned integration tests: if this is a viable option, then it will certainly help control the time
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I am a relatively new developer and have been assigned the task of documenting code written by an advanced C# developer. My boss told me to look through it, and to document it so that it would be easier to modify and update as needed.
My question is: Is there a standard type of Documentation/Comment structure I should follow? My boss made it sound like everyone knew exactly how to document the code to a certain standard so that anyone could understand it.
I am also curious if anyone has a good method for figuring out unfamiliar code or function uncertainty. Any help would be greatly appreciated.
The standard seems to be XML Doc (MSDN Technet article here).
You can use /// at the beginning of each line of documentation comments. There are standard XML style elements for documenting your code; each should follow the standard <element>Content</element> usage. Here are some of the elements:
<c> Used to differentiate code font from normal text
<c>class Foo</c>
<code>
<example>
<exception>
<para> Used to control formatting of documentation output.
<para>The <c>Foo</c> class...</para>
<param>
<paramref> Used to refer to a previously described <param>
If <paramref name="myFoo" /> is <c>null</c> the method will...
<remarks>
<returns>
<see> Creates a cross-ref to another topic.
The <see cref="System.String" /><paramref name="someString"/>
represents...
<summary> A description (summary) of the code you're documenting.
Sounds like you really did end up getting the short straw.
Unfortunately I think you've stumbled on one of the more controversial subjects of software development in general. Comments can be seen as extremely helpful where necessary, and unnecessary cruft when used wrongly. You'll have to be careful and decide quite carefully what goes where.
As far as commenting practice, it's usually down to the corporation or the developer. A few common rules I like to use are:
Comment logic that isn't clear (and consider a refactor)
Only Xml-Doc methods / properties that could be questioned (or, if you need to give a more detailed overview)
If your comments exceed the length of the containing method / class, you might want to think about comment verbosity, or even consider a refactor.
Try and imagine a new developer coming across this code. What questions would they ask?
It sounds like your boss is referring to commenting logic (most probably so that you can start understanding it) and using xml-doc comments.
If you haven't used xml-doc comments before, check out this link which should give you a little guidance on use and where appropriate.
If your workloadi s looking a little heavy (ie, lots of code to comment), I have some good news for you - there's an excellent plugin for Visual Studio that may help you out for xml-doc comments. GhostDoc can make xml-doc commenting methods / classes etc much easier (but remember to change the default placeholder text it inserts in there!)
Remember, you may want to check with your boss on just what parts of the code he wants documented before you go on a ghostdoc spree.
It's a bit of a worry that the original programmer didn't bother to do one of the most important parts of his job. However, there are lots of terrible "good" programmers out there, so this isn't really all that unusual.
However, getting you to document the code is also a pretty good training mechanism - you have to read and understand the code before you can write down what it does, and as well as gaining knowledge of the systems, you will undoubtedly pick up a few tips and tricks from the good (and bad!) things the other programmer has done.
To help get your documentation done quickly and consistently, you might like to try my add-in for Visual Studio, AtomineerUtils Pro Documentation. This will help with the boring grunt work of creating and updating the comments, make sure the comments are fully formed and in sync with the code, and let you concentrate on the code itself.
As to working out how the code works...
Hopefully the class, method, parameter and variable names will be descriptive. This should give you a pretty good starting point. You can then take one method or class at a time and determine if you believe that the code within it delivers what you think the naming implies. If there are unit tests then these will give a good indication of what the programmer expected the code to do (or handle). Regardless, try to write some (more) unit tests for the code, because thinking of special cases that might break the code, and working out why the code fails some of your tests, will give you a good understanding of what it does and how it does it. Then you can augment the basic documentation you've written with the more useful details (can this parameter be null? what range of values is legal? What will the return value be if you pass in a blank string? etc)
This can be daunting, but if you start with the little classes and methods first (e.g. that Name property that just returns a name string) you will gain familiarity with the surrounding code and be able to gradually work your way up to the more complex classes and methods.
Once you have basic code documentation written for the classes, you should then be in a position to write external overview documentation that describes how the system as a whole functions. And then you'll be ready to work on that part of the codebase because you'll understand how it all fits together.
I'd recommend using XML documentation (see the other answers) as this is immediately picked up by Visual Studio and used for intellisense help. Then anyone writing code that calls your classes will get help in tooltips as they type the code. This is such a major bonus when working with a team or a large codebase, but many companies/programmers just don't realise what they've been missing, banging their (undocumented) rocks together in the dark ages :-)
I suspect your boss is referring to the following XML Documentation Comments.
XML Documentation Comments (C# Programming Guide)
It might be worth asking your boss if he has any examples of code that is already documented so you can see first-hand what he is after.
Mark Needham has written a few blog posts about reading/documenting code (see Archive for the ‘Reading Code’ Category.
I remember reading Reading Code: Rhino Mocks some time ago that talks about diagramming the code to help keep track of where you are and to 'map out' what's going on.
Hope that helps - good luck!
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 12 years ago.
Imagine... You have written some code; implemented some interfaces, used some design patterns, passed many unit tests, extracted many methods for sake of refactoring and so. You developed, developed, developed... But at some mysterious point, for some reason you, something inside you started to whisper you that you should write a comment now. Something pokes you that if you don't write a comment something will be missing or something can be not exactly clear...
Then you comment your code! :(
Can this be a secret sign of a bad design?
If you find yourself in a situation that if you don't comment your code at that spiritual(!) moment, it won't have its mission completed; can we consider it as a reliable symptom of a possible bad design in your code?
If you're feeling like you should add comments because something is missing (documentation for clients perhaps!), then it may not be an indication that your code itself is bad. If you're adding comments because something is unclear, you need to decide whether it's unclear because the code is hard or because the underlying domain is hard. If it's the code, you need to rewrite it to make it clearer. If it's the domain that's making it difficult, feel free to comment it extensively for people who aren't as familiar with the domain in question, and leave the code alone.
While I agree that the code should be as self documenting as possible, this is not always enough. There is only so much you can do without writing comment. A good example is, as one of my mentor said : "Code can only document what you do, not what you dont do".
Even if you have the best possible design, there will always be places where you will need comments to make your intentions clear.
Comments can be usefull to document a tricky technical problem. If a problem is complex, its implementation will be complex and will need documenting.
Comments are also usefull to document business rules. Those rules will be expressed into code, but the code will rarely explain the reasons behind the rules. Comments will make things clearer ...
Sometimes writing comments is easier than cleanup your code to make it clear enough the understand what it does and why. I usually do the later, but comments can be the best approach at times. esp. if you generate javadocs.
I tend to do this when I've already tried several other approaches which didn't work, in an effort to stop myself coming back in a few months, and trying to refactor back to those approaches again.
I put this as an asnwer because I think it's important. Basically I agree with Stuart:
A coding standard at a previous job said to only ever comment code if it is dealing with something exceptionally computationally difficult such as a complex compression or encryption algorithm. That company had the best damn code I have EVER seen and I have worked in a wide range of different types of company.
As much as I agree with everyone who is arguing for self documenting code, there is one place I feel they overlooked where comments are important: Interfaces, and to a lesser extent, abstract methods. The contract on an Interface method is usually (and probably should be) more complicated than can be described in the method name. The only way you can document that is with a comment.
If code falls into standard patterns with sensible method names etc then it's often not necessary to comment. However, often I'll write a quite short routine that does something nifty, usually involving a good dollop of maths and a bit of swishy logic. I'll usually comment every line of something like this, as if I don't I'll come back to it later and look at it and think 'Why is it doing that?' whereas if I've commented it it's so so much easier. It saves me a minute or more of re-thinking the problem every time I look at it.
So to answer the question, No, not necessarily.
Dittos to Guillaume. I strongly disagree with those who say that if you just write your code clearly enough, comments are unnecessary.
Yes, it is surely true that some types of comments are unnecessary if you just use meaningful variable and function names. Like, why write:
x17=bbq*rg; // Multiply price by tax rate to get tax amount
Better to write:
taxAmount=price*taxRate;
And I just find it mind-bogglingly annoying when someone writes a comment that just restates what any competent programmer should be able to instantly tell by reading the code. I don't know how many times I've seen useless comments like:
x=x+1; // Add one to x
Like, wow, thanks for telling me what "+" does. Without the comment I might have had to Google it.
But there are at least three types of comments that I find very useful:
Comments that explain the overall purpose or approach behind some large block of code. Something that gives me a clue why you're doing what you're doing. Like, "// When the delivery location is changed, recalculate the sales tax using the rates applicable to the new location". Sure, I could hack through the code and ultimately figuring out what you're doing, but if you tell me up front, I don't have to figure it out. This isn't supposed to be a game where we see how long it takes me to solve the problem. Just tell me the answer.
Comments that exlain how a function should be called or how to use an API in general. Like, "To retrieve the pricing data, first call contactPricingServer to make the connection, then call getPrice for each item you need a price for, and finally call closeConnection to release the resources." Maybe if I studied all the available functions long enough I could figure that out, but again, this isn't supposed to be a quiz. Just tell me the answer.
Probably the most valuable of all: Comments that explain a piece of code that might not be obvious. Like, "We must look up by sale date and customer number rather than by sale id because the sale id's on the recon server aren't updated until month end." I've had plenty of times that I've looked at some code that looked strange and wondered if it was a bug or if there is some good reason why the programmer did it that way. The problem is not that I cannot figure out what the program is doing. The problem is why it is doing X rather than doing Y, when Y seems like what it ought to do.
Update
I have to laugh. Right after making the above post, including the remark about useless comments that just restate what the programmer can instantly see from looking at the code, I went back to doing some real work, and the next piece of code I looked at said:
// Set the sales status to "S" and the delivery date to today.
setSalesStatus("S");
setDeliveryDate(today);
Like, wow, thanks for that helpful comment. That cleared up all my confusion immediately. Because, you see, the REAL question that I'm trying to figure out is, Why are we setting a delivery date here? This doesn't appear to be an appropriate place to be doing that. But instead of a comment that explains the purpose of the code, all I have is a restatement of the obvious. Arggh.
Personally, I always comment my code. No long lines, but short bits like
// parser starts here
...
// mail!
etc.
However, if you have a 5 line script, commenting might be a bit overkill... especially if your filename says it.
If it's for you, and you alone, you totally should do it if you feel like it. If you're working on something with a team, I'd do it always. Just to notify the others what they're looking at.
Comments and bad design are two different things. Comments help to understand certain things in a bigger context. Comments (and documentation in general) help new folks in a project to do some reading on their own.
Actually we have some unwritten rule that we must comment our stuff. If I wonder whether or not somebody can understand this at first glance it's already a sign of a required comment.
However, it's not a sign of bad design.