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 10 years ago.
What are some common practices you have seen used in the design by obfuscation crowd? I find it interesting to be on projects that are not allowed to be rewritten while, that would be the faster and most efficient solution to the problem.
My favorites always revolve around variables...leaving ones in the code that are no longer used, then giving them all meaningless names. Of course, you have to be careful to avoid nearly all convention if you really want to obfuscate. So, a perfect one would be to have two similarly used variables, one named myVar1, and another named myVarOne. Stuff like that...
Another one is to include un-used controls that are only visible within the code. I stared at one ASP.NET site for a good hour trying to figure out why a FormView was dropped into it..(there was no answer to that).
I once worked on perl code where the author decided to have most of the subs receive a single hash as a variable and returned that same hash with data added or removed. Basically one global hash used to pass data through the different code paths.
It looked something like this:
my $hash = ();
$hash->{'CUSTID'} = 1001;
$hash = GetAccounts($hash);
if ($hash->{'AccountTotal'} > 100) {
$hash = getTotals($hash);
$hash->{'Acct_Sbkt_Marker'} = 'R1';
$hash->{'Acct_Invr_Marker'} = 'BT';
$hash = removeInvalidAccount($hash);
}
To this day I can't figure out what design pattern he was trying to implement with this.
I remember the $hash would be lined up nicely.
We had one person we worked with store files in a folder call /kensington in order to "hide" them. It just contained some xml files that he didnt want seen and figured people wouldn't look in there.
No or useless comments in the code along with no useful documentation.
I worked with a programmer that used to write hugely complex conditions that when met would call a method that simply did a system out. He did this dozens of times throughout the entire app. Still not sure why....
And there I was thinking that well designed code should stand up on its own to be read, not deciphered.
I understand that people who care about obfuscation are encouraged to use tools like dotfuscator and its equivalents in other environments. Obfuscation in the sense of making the code harder to decompile though, not just making it a pain to work with.
Why anyone would deliberately design horrible code (except to demonstrate the gotchas) is beyond me.
Related
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 11 years ago.
I've been developing in Objective-C for a long time, mostly games, and lots of people have commented that I frequently use global variables. For example, in my .m file before the #implementation I mostly have:
BOOL X=0;
int y=1;
NSString *ran;
.
.
.
Now, I know I have to use properties, but I've found it much clearer for me to use this global variable, and I'm keeping them safe.
Except for the fact that it is not object oriented and/or not acceptable, does it affect any other facet of my app, like processor operation?
In my games I have something like 40 booleans in 1 class that are shared by almost ALL methods. I find it almost impossible to write getter/setter, or use properties for all of them, and I am comfortable with my way. But is it so wrong?
Is there another way to deal with many booleans that change in real time frequently, and are shared by all methods?
Is this so terrible to use globals? (I dont need to be considered as good Objective-C user…)
Global variables are generally considered bad practice because they lead to coding problems in the long run. If you find yourself able to maintain your code, then go ahead.
But eventually, you'll work on a project big enough where it will cause problems. Why not learn to get along without them now on the easier projects?
ObjC's not much different from its relatives in this regard.
The problem is that the program is very difficult to use in other contexts. That is, it can be a better choice to reimplement a program entirely rather than making the one with 40 globals reusable (and retesting everything).
40 Booleans for one class is also a llllloooooooot. Read your code -- look for patterns. Make smaller, more easily reusable implementations if you want to get away from the globals. Many devs consider them huge maintenance pains (war stories!). I could easily see myself having trouble trying to understand the program flow of such a program.
Even packing your 40 bools into a C struct and putting an instance of that struct in your ObjC class will be one huge improvement which is simple to implement.
If you have had no problems maintaining these programs, consider it a blessing! …but it will not be a favorite design for other people that will read, extend, or maintain said program.
As with most development practices, global variables have their place, BUT they reduce how refactorable, readable and debuggable the code is. Imagine the following scenarios:
a program that has an error in one function, but the error is caused by a global variable. Which other location produced the bad value? It's nearly impossible to tell.
someone who didn't write the code wants to change something, but has no idea where the global values are coming from. The way to figure out how the program works is to understand EVERY place the global variable is used. This is much more difficult than if you had simply encapsulated your functionality appropriately.
one piece of code is repeated over and over again (every method has access to your global so they all use it, but in just barely different ways). Requirements change and you need to change how that works slightly. You now have to change 143 different places in the code. (one time I had to do this was when the software changed from the English system to metric. 30 different code locations all using DIFFERENT conversion values to do the same thing)
On the other hand, if you have performance issues, there are times when having a global will speed things up, but it's much better to code for readability, refractorability and debuggability and then refactor if necessary for performance.
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 11 years ago.
sometimes i'm using OO des. and sometimes procedural style and everytime i use oop i feel like wasting resources on nothing. say i have a situation where i need to grab some values from datasource, a pool of bannerinfo. For the further work i can declare a banner class and decorators for additional functionality, but why would i do such a hard sequence - i got to grab, instantiate objects, fill them, wrap and so on, rather then just: grab data, run procedural code on data; yeah in many times oop just helps to organize logic and make decisions flexible, but on the other hand it's a waste of time on design (i experience a lot of problems solving simple stuff while putting them into oop style) and obviously a waste of machine resources. i'm kinda stuck in that mindset, im young but i've already seen some projects in oop - i wouldn't say that they're easy-understandable; that idead of oop is pretty charming - organising, making logically, but...
So, would you mind to point out some difference between situations when i should use oop/procedural styles. I'll appriciate any links to additional literature on that topic.Thanks!.
That data you're grabbing has a structure to it, i.e. the order in which the fields show up within each record in the data source. The code you want to run on that data is closely bound to that structure (i.e. the code is not going to apply to other data structures, and if the data structure changes you certainly want to change the code). So it makes sense to keep the data and behaviour together from a "mental information management" point of view, and object are a great way to do this.
What if your program grows, and you want to iterate through bannerinfo in multiple places within the project? Of course you could create a routine available from the whole program which does what you want on the bannerinfo, and call that from each point where you need it. But what if you then think of other things you want to do with a bannerinfo? Of course you could just create another routine available from the whole program, but it would be completely separate from the first. What if these two routines had some code in common that you could push out to a separate routine, would you create yet another routine available from the whole program, even though it's only used by the other two?
With OOP you'd have a class with two public methods, and one private one for that third routine. Why is this different to having three routines available to the whole program? The answer is clutter. You can create as many additional methods on that class, and it won't add clutter to the parts where you're not using that particular class as they won't be available. If the data structure of bannerinfo changes, you only need to go to one place to make the changes.
Of course there's more, but I hope this helps demonstrate where OOP can be useful. Its all about making it easy to manage. If your specifc problem doesn't care for that because it is a one-off, or will never grow, then there's not necessarily any benefit.
Final note: whether the benefit is worth the effort also depends on other factors such as how comfortable you are with using objects, what you're trying to do with them (inheritance can get murky), and also on the language and syntax itself.
"grab data, run procedural code on data"
I don't see how dealing with data can be easier with procedural. With OOP you can do stuff like
$users = $db->from('users')->where('score',100,'>')->getMany();
Or with an ORM:
$user = $orm->entity('User')->findOne($id);
$user->setPassword('abc123'); // set a new password
$orm->save($user);
About showing the data (also called 'the view' in MVC architecture), I have to agree that decorators can be annoying. But if you use a templating engine, things are easy as they can get. You didn't mention which language you are using, but if you are into PHP you can use Twig
Personally, I feel more comfortable with OOP even in small projects, where you don't even do things like unit-testing. But I think the best of OOP comes when you need maintainability, collaboration, reusability, etc.
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 10 years ago.
Currently my best tool for this is a thesaurus, but I would like to expand my horizons on the matter.
Invest in a tool that makes refactoring easier. Like in NetBeans, you can easily rename classes and variables. If you use that, you can make a mistake without much problems.
But it is wise to think about the structure of names.
A class I think of as an entity, so its name is noun, like Customer is the name for a class respresenting a customer.
A function (and method too) is a verb. It describes what it does, like getName() returns the name. get and set are common prefixes for functions that return or set a property. That's why they're even called 'getters' and 'setters'. A function name could also be saveCustomer to save a customer, or just save, if it is a method of the customer class.
With some basic rules like that, it should be easy to come up with a reasonable name, which you can always change using the refactory tools found in many editors.
Sometimes it is hard to find a good name. I'm not a native english speaker myself, while the code I write (and the comments) is in english, because it conforms more to existing libraries. Sometimes I find it hard to find the right word. In that case I use a disctionary or just Google to find a translation. Usually googling for 'WordInYourLanguage translation' will give you a list of entries on dictionary sites, from which you probably will recognize the right term.
Sounds a bit OCD to me...
Most of my code does not face a 2nd pair of eyes, so I sometimes name my variables things such as "BigBoobs"... At the end of the day, the only people that need to know the variable are you and anyone else who may be looking at the code...
As for seriously addressing your question:
I don't think there would really be a variable name generator out there, because that would involve it knowing what your program is actually doing as you do it. If technology like that exists, I guess I will be out of a job.
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.
I have seen some people who refuse to use Interface Builder and prefer to make everything using code. Isn't this a bit tedious and doesn't it take longer? Why would people do that?
This is usually a holdover from working in other environments with other UI builders. A lot of UI builder programs are viewed as newbie hand-holding at best and outright harmful at worst. Interface Builder is unusual in that it's actually the preferred way to create interfaces for the platform.
Some people don't like mixing code functionality in interface designs. Another example is when flash devs would include lots of code snippets directly in the stage (fla files), rather than in separate .as files. With xib it's not as big of a problem, since they are xml and can be merged quite easily when using source control. I personally like using xib's because we have a team of devs and designers -- splitting up the work load is nice. The designers can easily port their photoshop/fireworks designs into xibs and we can focus on the functionality.
Sometimes you want to do something that the UI builder can't quite handle (these situations aren't common, but they do come up now and then). Sometimes you may feel you have better control over what's happening when you write the code yourself. Me, I prefer to let the UI builders do it as much as possible, but sometimes it doesn't always work that nicely, and I sometimes have had to write the code myself.
Possibly because the Interface Builder is another tool to understand. Also, it's useful to know how to do things programmatically in case nibs don't give you enough functionality.
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.
I don't think I am a total noob in OOP, but do you sometimes feel we go a little too far in privatizing the fields? Do you have a good rule of thumb as to when a field absolutely must be private, and when is it (maybe) okay to mark it protected, or public?
Sometimes it's the obvious thing that gets me.
Discuss
The simple rule:
Interface should be public. Implementation should be private.
When you make a field public (or even protected), you are effectively declaring it as part of the interface. Problem is, it's an implementation detail -- in almost every case, that field means something to your code. Anyone that wants to set it can, but you have to carefully explain how it needs to be set in order to keep the whole thing from crashing and burning. You can't even validate it as it's being set, so you need to validate it every...single...time before you use it, which can kill performance depending on how the validation needs to be done. (Even then, there's no guarantee that the field will stay valid, because you can't even enforce synchronized access to it.) And everyone using your class will have to do the same thing, cause $DEITY only knows what other code has been mucking around with that field and possibly corrupting it.
On top of all that, once it's a field, people are going to write code that expects to use that field. And in the cases where you find you need any of that validation later, you can't just convert a field to a getter/setter without breaking binary compatibility (meaning anyone who used your code will have to recompile everything that used that field in order for it to work again). Do that too many times, and people will be afraid to use your API -- read: you won't have any users.
Getters and setters separate the implementation from the interface. They allow callers to get back something that is definitely valid, and let you make sure that anything going in is definitely valid. This makes things more predictable, more stable. So if you write code that will ever be used after you write it, non-trivial getters and setters (that validate the value, maybe synchronize, etc -- ie: do more than just blindly get and set a variable) are a good idea.
It's for the case when others are going to be using your code or classes. You can expose and control exactly what is to be interfaced with, and what is 'internal.'
If you're the only one who will ever use your code, then yes it is often going 'too far.'
I will get attacked for even suggesting this, but whatever...