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 noticed that the Smalltalk language has no concept of private/protected methods. All methods are public. Coming from a Java/C++ background, I've thought of this as a fundamental weakness in the language as any application created in Smalltalk would be completely open to manipulation. I guess you could rely on naming conventions to document the public API and prefix methods to indicate them as private (I believe Squeak does this), but it's still completely open.
Are there any benefits to this approach over having explicit access modifiers to control
access to method invocations?
Indeed, the Smalltalk way is to put private methods in the 'private' category. This indicates that you shouldn't use these methods, but of course doesn't enforce this.
This is by design - it's a feature, not a bug. Smalltalk was designed from the beginning precisely to be an open system.
Some advantages:
If I simply have to - maybe the library designer didn't foresee a need to expose some particular thing I simply have to have - I can still call those private methods. Obviously, this isn't something one does lightly: rather, judiciously, cautiously, knowing that it's a tactical solution.
Language simplicity.
(As per Alexandre Jasmin's comment) Smalltalk makes no distinction between what you, the programmer, can do and what the language/environment can do. That means that Smalltalk-the-image exposes all the things needed for you to build your own inspectors/debuggers/whatever without having to supply special tools using we-can-do-this-but-you-can't techniques.
Private and protected methods are in fact a significant weakness of languages like c++, java and c#. They basically say to their users: I don't want to learn and evolve. The consequence of that (and a lot more early binding) is that those languages require much more BDUF and are thus far less usable for a modern (agile) development process.
The first question is what private/protected access modifiers are about? Fundamentally, it is not about safety or security. It is about exposing the right interface to the user. Starting from that, it makes little difference between having categories protected/private and a language construct specifically for that.
I would even say that having private/protected visibility modifier brings more complexity to the problem than it actually solves.
Besides that, I don't think that private/protected visibility is a good answer to this problem
At the least, Smalltalk should have the textual convention that method names that begin with 'underscore' are verboten to call outside of the objects themselves. Unfortunately, I don't think that 'underscore' is allowed as the first character of a method name.
Related
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 9 years ago.
Improve this question
I am teaching an upper-division software engineering course and am reviewing every student's code. Some of my students have picked up the habit elsewhere of adding a comment to the right of every closing brace identifying the statement type, such as:
if (x > 3) {
y = 10;
} //if
I have told the students to follow the Android code style guidelines, which says nothing about this practice. On what grounds should I tell them not to do this (besides personally not liking it), or should I permit it?
Comments are for clarifying code and increasing readability. It's clear enough to most reasonable software developers that the statement is an "if." Furthermore, many IDEs and editors automatically highlight brackets such as these, so the comment isn't necessary. Generally, you should save comments for describing what methods, classes and variables do (e.g. in Javadoc), or what subroutines within a method will do. This is based on the general guideline of making sure everything you add improves the code.
Tell them that they should assume that person who review code knows language syntax and how to program. Comments should be rare, indicate and explain some weird and not obvious code section (for instance the api provided by some library is bugged and some workarounds/hacks are needed). We've got documentation (and unit tests) to explain how to use and how code should behave. For educational purpose you can write small class/module filled with such "comment-documentation", give it to students and ask them what did they learn about code from these comments.
Well, most likely this will end up in a discussion based on personal preference - which is not within the scope of stackoverflow. But aI'll answer anyway:
In my opinion, that's a bad thing to do - for multiple reasons.
It messes up the code. the more comments are in there, the less readable it is. A single } in a line tells me, instantly, that the last block ends here. with the comment behind, there is more to read - and no additional info (but people will read anyway, cause they don't know that the comment doesn't include any info... and because people tend to read everything automatically)
It leads to sloppy indentation. After all, that may even be the reasons people started that in the first place.
it's unnecessary - if I indet the code in a consistent manner, it shouldn't be necessary to note what was closed, it should be easily visible by just going up to where the last statement with the same indentation level was. In most cases (unbless you're reverse-indenting (or whatever that is called), which I don't like at all) this should be very easy, as there is nothing in between...
it leads to bigger file sizes. may be invalid on modern systems, but still.
Every time is overkill. It depends on the level of indentation and the length of your function, but these are usually signs that you need to step back and refactor. The only time I explicitly do it is for namespaces in C++
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 7 years ago.
Improve this question
Most Ruby constants follow the C convention of having all caps.
But is it considered legitimate style to name Ruby constants using CamelCase? I just think it is easier to type that way, since my Caps Lock is remapped to CTRL.
According to the ruby specification, modules are constants. There is a philosophy behind it, and there is no reason they should be written differently. If modules are written in camel case, why not for the rest of the constants? Although writing in upper case seems to be the majority, I do write them all in camel case. In addition, writing in upcase reminds me of the classic languages like Basic, Fortran, etc., and does not look sophisticated.
ecologic points out compatibility with IDE, but if that causes a problem, then it's the IDE's bug. An IDE should follow the language's specification as strictly as possible, not the convention that people follow.
Well, you should ask to the people in your team and get a common decision, as you don't want two conventions in the same project.
In my opinion it's always a good idea to follow the proper convention of each language. I follow conventions that I don't really like. Also some IDE could interpretate the constant differently.
No, it is not considered legitimate style to name "other" (non-class, non-module) constants using CamelCase.
Standard Ruby practice is that classes and modules are CamelCase; other constants are SCREAMING_SNAKE_CASE.
Ruby will permit you to use CamelCase for other (non class, non module) constants, but you will surprise everyone who reads your code. The purpose of code isn't just to communicate with the machine, but to communicate with anyone who must understand your code. For that reason, you should adhere to the widely accepted standard in this case.
Evidence
All of the style guides I found on the first page of a google search for "ruby style guide" which have anything to say on the matter support my claim that SCREAMING_SNAKE_CASE is the overwhelming majority standard for naming non-class, non-module constants in Ruby. A few quotes:
https://github.com/bbatsov/ruby-style-guide#screaming-snake-case:
Use SCREAMING_SNAKE_CASE for other constants.
https://github.com/styleguide/ruby
Use SCREAMING_SNAKE_CASE for other constants.
http://www.caliban.org/ruby/rubyguide.shtml#naming
Constants should be named using all upper-case characters and underscores, e.g.
BigFatObject::MAX_SIZE
https://www.relishapp.com/womply/ruby-style-guide/docs/naming
Use SCREAMING_SNAKE_CASE for other constants.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 12 years ago.
Personally I can't stand region tags, but clearly they have wide spread appeal for organizing code, so I want to test the temperature of the water for other MS developer's take on this idea.
My personal feeling is that any sort of silly trick to simplify code only acts to encourage terrible coding behavior, like lack of cohesion, unclear intention and poor or incomplete coding standards.
One programmer told me that code regions helped encourage coding standards by making it clear where another programmer should put his or her contributions.
But, to be blunt, this sounds like a load of horse manure to me. If you have a standard, it is the programmer's job to understand what that standard is... you should't need to define it in every single class file.
And, nothing is more annoying than having all of your code collapsed when you open a file. I know that cntrl + M, L will open everything up, but then you have the hideous "hash region definition" open and closing lines to read.
They're just irritating.
My most stead fast coding philosophy is that all programmer should strive to create clear, concise and cohesive code. Region tags just serve to create noise and redundant intentions.
Region tags would be moot in a well thought out and intentioned class.
The only place they seem to make sense to me, is in automatically generated code, because you should never have to read that outside of personal curiosity.
I like regions, and use them all the time. I use them to group members of the same kind inside classes.
You already have the means to collapse methods, classes and namespaces in the editor. Regions give you an option to create another level that lets you arrange the code in a way that corresponds to what you think is important.
StyleCop doesn't like regions:
SA1124: DoNotUseRegions
Cause
The C# code contains a region.
Rule Description
A violation of this rule occurs whenever a region is placed anywhere within the code. In many editors, including Visual Studio, the region will appear collapsed by default, hiding the code within the region. It is generally a bad practice to hide code, as this can lead to bad decisions as the code is maintained over time.
How to Fix Violations
To fix a violation of this rule, remove the region from the code.
There is some discussion about whether or not this is a reasonable rule.
The consensus seems to be that some people like regions and some people don't - it is up to individual teams to decide. The most important thing is to use a consistent style throughout your project.
One place where regions might be acceptable is to group all the methods that implement a particular interface. It is worth noting that Visual Studio automatically adds a region if you use the code generation feature to provide method stubs for implementing an interface.
The only place they seem to make sense to me, is in automatically generated code, because you should never have to read that outside of personal curiosity.
The partial class feature is better for separating automatically generated code from manually generated code within the same class.
When working with automatically generated source, code can be added to the class without having to recreate the source file. Visual Studio uses this approach when it creates Windows Forms, Web service wrapper code, and so on. You can create code that uses these classes without having to modify the file created by Visual Studio.
I think that #region is perfectly fine. I've never used it myself, but if you have a large or complex class, it can help with finding what you're looking for. Imagine if you're implementing ID3D10Device1- that's over a hundred methods to implement. You want to just throw them all in one place?
I do use regions to organize bigger constructs in a class, ie. a Dependency Property with callback and methods getting called by this, eg. you have a DP that takes an IEnumerable<T>, and you want to use the weak event pattern to respond to INotifyCollectionChanged. This can take some code, and as I won't be touching it after coding it, I put it in a region.
However, if you resort to regions to structure your logic, this is severe code smell and that's what the StyleCop rule in Mark's post is pointing hat.
while I am programming I use regions a lot they help me keeping my code organised and be able to focus only on parts I care. I always add comments on the regions and what are they about .But when I am done I am always removing them. Its a handy tool, that's all.
IHMO, if you have #region section in a class, it means that you have two behaviors in your class and so you should split your class in two objects.
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
If you are given a large n-tier project (.NET) with 15,000 lines of code written in "Spanish" (variables, tables, classes names etc) that requires feature addition and bug fixing, what would be your strategy to work on it?
Converting the whole project to English(Google Translation or other tools) names does not seem to be a good options as it will be time consuming
Hire a developer who knows "Spanish" or a translator
EDIT: The developers who wrote the original software does not understand English so they are not useful in this case.
Attempt to work on it as it is without translating anything. If it doesn't work, start translating it on-demand, only pieces that are relevant to you.
A dictionary can get you quite far already. You can translate code elements on your own. Naturally, don't add any more pieces to the puzzle. What you add should be in English.
I would also notify the customer that due to the code being written against common sense and best practices in non-English (and even unfamiliar to you language) there will be a delivery delay. Blame on the original creator of the novel.
Unless this is The Project From Hell, there should be far fewer than 15000 variables and methods in your code. My on-the-cheap suggestion would be for you to extract a cross-reference list of variable names as found in your program, hire a quick cheap Spanophone to translate those names for you, and then keep the translation list handy as you and your teammates code.
It's handy to have an idea of what is meant by a variable name, but it's not essential. I spent 20 years writing programs with only 4 significant characters in the variable name.
It's subjective, but my personal opinion is Option B) Hire a developer who can speak spanish - primarily because all the commenting will likely to be in spanish and if the commenting has been done well - it will have valuable information within that should not be ignored / lost.
A translator might not be able to understand the terms within the comments / code and a translation by a non programmer could go bad.
Best option would be to get in touch with the guys who wrote the darn thing...if possible at all. Second best, a developer who knows Spanish.
Translate your classes first. Then you should be able to keep track of instances by their type.
Sorry mostly questions.....
Is the customer a Spanish speaker? If so the software should be written by a Spanish programmer. As the cost of communicating with the customer is a lot less if the programmer understands the customer.
If the customers is not Spanish, why was a Spanish programmer used at all?
Was the Spanish programmer chosen to save money?
If so, is the software worth keeping at all?
How can you tell how good the code is if you can’t read Spanish?
I think the translation should be done as needed on demand, e.g
All new code should be in “English”.
All methods that are changed should be in “English”
All class/methods the new code uses should have English names and summary comments.
The names and comments on all unit tests for class/methods with English names should be in English
Missing unit tests should be written for any class/method when it is not clear what the spec is. (So as to check the translation of the comments into English.)
I think a willing English programmer will be able to use Google translate to do the above, however as with any new source code base, the programme will have to spend a long timer really understanding what each class/method does before using it.
An English programmer that knows some Spanish would be able to do it quicker. However don’t use a Spanish programmer, as you always want a translator translating into their native language.
First step, and this is true when you inherit a legacy code base whether it's in your native tongue or not, is to set up regression tests based on "known good" output, and begin writing more tests as you go, for the changes you make.
Quite possibly, given the relatively small size of the code base, you will fairly shortly start to understand what various routines are doing, and may be capable of beginning the translation effort yourself, maybe supplemented by automated translation.
This assumes you understand the problem domain, and that the original code was written professionally.. although if it were, you'd already have tests, wouldn't you? You don't mention whether that's the case.
Doing anything here without regression tests is foolhardy. Doing it with tests, you may find the whole task relatively manageable and don't need a serious translation effort. Definitely respect the other suggestions to do this incrementally too.
I can get all of methods, fields, annotations and etc. with reflection methods and etc. to export excel or etc. Then I can send this excel file to spanish translator. After translated, i can convert all of project codes by reference which is translated excel file by text processor applications (find / change etc.)
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 10 years ago.
Improve this question
While going through university and from following the development of SO, I've heard a lot about the Model-View-Controller architectural design pattern. I inadvertently used the MVC pattern even before I knew what it was, and still use it in my everyday job. From what I've seen, it's probably the most popular pattern used today. What I haven't heard much about though, are the alternative patterns you can use instead of MVC. What options are there, and for what reasons would you decide to use them over MVC? I'm also interested in knowing the types of systems they are typical of being used for. Finally, what are the pros and cons that come along with using them?
Passive View - http://martinfowler.com/eaaDev/PassiveScreen.html
Supervising Controller - http://martinfowler.com/eaaDev/SupervisingPresenter.html
Model-View-Presenter - http://martinfowler.com/eaaDev/ModelViewPresenter.html
My personal favorite is the Passive View. More testable than others I've seen including MVC.
Some other architectural patterns including MVC.
Layered Systems
TCP/IP
Object-Oriented Organization
Model-View-Controller, Presentation-abstraction-control, Model View Presenter and Model View ViewModel.
Examples would be ASP.NET's MVC, Ruby on Rails, and bunch of others.
Event Based, Implicit invocation
Browser environment (DOM)
Pipe and filter architecture
Unix pipes
Repositories
Table Driven Interpreters
You may also find this paper by Garlan & Shaw on Software Architecture a nice read.
Another noteworthy link would be the article on architectural patterns at Wikipedia.
I've occasionally seen MVC without the C, where the view listens for changes in the model's data and alters rendering accordingly, and where the methods in the model are bound to event handlers for the view.
For projects where the view is by necessity tightly couple with the data (such as when there are visual components that directly relate to the model or attributes of the model), this can be rather useful, as it cuts out the "middle man."
I think many would argue, though, that this is still MVC, just a hybridized version, and that the bindings established between the view and model are controller logic.
Well, there's Model-View-Presenter, but I think you'll find that the most common "alternative" to MVC is really a lack of proper separation. As an extreme example, consider classic ASP pages where HTML, VBScript and SQL are found side-by-side in the same file. (That's not a bash of ASP — you'll find plenty of such examples in other languages.)
Although the above answers are quite correct, I think it's much more important to note that the words "design pattern" are completely unknown to 90% of all people who create software. They just start writing code.
The challenge is not selecting the best design approach, it's convincing others that design has value.
Well it is quite old now. I would like to mention one more (in the interest of info for additional knowledge) is PresenterFirst patrern
Here is more information on the same:
http://en.wikipedia.org/wiki/Presenter_First
http://www.atomicobject.com/pages/Presenter+First
HTH
The Presentation-Abstraction-Control (PAC) family of patterns, where interface/interaction is handled by a hierarchy of agents.
The wikipedia article is not great
http://en.m.wikipedia.org/wiki/Presentation-abstraction-control
In the Lift web framework we use a View First approach. Basically a view is composed of one or more snippets (somewhat similar to controllers) and snippets can be nested. This works very well with HTML and Scala's built-in XML processing capabilities.
You can roll your own MVC with the current ASP.NET framework and still keep the postback model.
http://www.codeproject.com/KB/aspnet/RollingYourOwnMVCwithASP.aspx
What about the Observer pattern. If I am not mistaken , MVC was introduced in Smalltalk and thereafter several publish/ subscribe patterns have come into picture.
The observer pattern (a subset of the publish/subscribe pattern) is a software design pattern in which an object, called the subject, maintains a list of its dependents, called observers, and notifies them automatically of any state changes, usually by calling one of their methods. It is mainly used to implement distributed event handling systems.
Ex : The Save button gets enabled in an editior, only when there is data to be saved. Another example of the observer pattern is Document View architecture in MFC, where in the view gets updated when the document changes .