Coding Horrors: You can gather all your technical debt into one easy framework!

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Coding Horrors: You can gather all your technical debt into one easy framework!

«‹›1501 »

such a nice boy: Mar 22, 2002

Scaevolus posted:

http://luke.breuer.com/time/item/MeditechCodeProcessor/318.aspx

What's wrong with it? There's no way I'm going to make the mental effort to try to parse out what that regex does.

# ? Mar 29, 2008 22:53

Adbot: ADBOT LOVES YOU

# ? Apr 26, 2024 05:48

hey mom its 420: May 12, 2007

such a nice boy posted:

What's wrong with it? There's no way I'm going to make the mental effort to try to parse out what that regex does.

Hehe, I think that's exactly what's wrong with that code.

# ? Mar 29, 2008 23:16

tef: May 30, 2004; -> some l-system crap ->

nebby posted:

For example, if you are writing a method called countOfApplesInBasket() that returns a count of apples, if I see the line "result += 1;" I have to look at context to determine wtf result is.

The best bit is I don't even have to think up new jokes, you're still saying the same things.

Mainly because a lot of people will waste a lot of time arguing with you, here is what I see as the condensed nebby experience:

Fake Nebby posted:

Naming schemes are hard to get right. Thus we should use a series of cryptonyms to identify each indivudal type. The best thing to do is mmenonics for each data structure used.

For example, Say I wanted to store a list of student scores

– Bad Idea studentScores = { 'james': 80 , ... }

See, I don't know the type of information that studentScores is - names of variables should reflect the implementation rather than the intent. You don't seem to understand that "Human Readable Names are Evil".

Now, what we are actually storing is a hash which uses student names as keys (strings) pointing to percentages (ints). This leads to the obvious naming scheme

scr_pcn_int = sn_str_hash_scr_pcn_int[sn_str]

Now, when I look a this I can see that we are retrieving a percentage score in an int from a hash using a string containing a student name.

The other reason this is a fantastic idea is that context is really hard, I mean, when I read a sentence and the word "james" appears, I don't understand what it is refering to, unless I prefix it with the relevant information.

Really, when you're looking at code — you do so at one lexical token at a time — this is why we have to ensure that we have all the information to hand.

Now, let's take a function written by some amatuer programmer who has yet to reach my level of enlightenment:
code:
class AppleBasket
   count = 0
   def addApple(s)
       s.count++
   def takeApple(s)
       s.count--
   def numApples(s)
       return s.count
If I were to ignore the surrounding context of the program and focus on one part alone, say return s.count I have no idea what it means. Anyone who will edit this program will only see this line and they will be confused.

Redundant information is the key. Succinct code is useless. To demonstrate this I have improved the above program
code:
class AppleBasket
    int_app_cnt_tot = 0
    def addApple(applebasketself)
        applebasketself.int_app_cnt_tot++
    def takeApple(applebasketself)
        applebasketself.int_app_cnt_tot--
    def numApple(applebasketself)
        return applebasketself.int_app_cnt_tot
Although this looks like apps hungarian, and we are encoding the types of variables into the names, you are wrong and it is Systems, because I only do the good hungarian notation.

Now, when I see the line return applebasketself.int_app_cnt_tot I know exactly what it returns. I can finally trim down the excess space on my screen and get down to editing code with only one line displayed at a time.

I am hoping to apply this same system to make my forum posts more readable. You see, even comments and text can be analysed in the same way - one logical token at a time.

I could write something like /* calculates the size of the basket */, but that isn't obvious enough.

Remember "Human Readable Names are Evil" — what type is basket, what type is size, how it is calculated?. I think the new comment should read something like /* arith_calc:: int_size(apple_basket) */

This sort of redundancy defeats the enemy of the working programmer — context!. We need to keep at it. When I see a function like add(...) I have no idea how many arguments it takes. I am in the process of renaming all of my functions to have the arity appended to the end, so add(x,y) becomes add_takes_two_args(x,y). I would use add2(x,y), but you wouldn't know if it was the second adding function from the name alone.

Hopefully my methods will become widespread, and we can put an end to all of this uncessecary confusion.

On a more serious note — I did give up trying to debate the merits of nebby's ideas given his inability to argue them consistently (Apps vs System being the most obvious example).

(Edit: Another is that although you realise that inconsitent naming schemes are bad, you are yet to realise that a consistent naming scheme can be bad in a completely different way. You point out the trivial flaws of others (NumChild/NumChildren), hammer home ambiguitiy I've rarely seen and focus on statements at a macro level. You then take these as support for your scheme, rather than being innacurate criticisms of straw men)

Really his system of naming speaks more about his command of the english language (and his comfort in using it) than it does about his ability to program. It boils down to "Hungarian Notation will free you from the Tyranny of understaning things in context".

nebby posted:

You're forgetting that I explicitly said in all my posts I intentionally post on subjects that are controversial in order to spice things up.

A troll by any other name would smell as foul.

tef fucked around with this message at 06:05 on Mar 30, 2008

# ? Mar 30, 2008 05:51

Zombywuf: Mar 29, 2008

pokeyman posted:

Found this in the PHP manual. It's like the guy knew he wanted some kind of conditional execution, but forgot about the "if" keyword.

code:

switch (TRUE)
{
 case ($phlen < 7):
   $ext = $ph;
   break;
 case ($phlen == 7):
   sscanf($ph, "%3s%4s", $pfx, $exc);
   break;
 case ($phlen > 7 AND $phlen < 10):
   sscanf($ph, "%3s%4s%s", $pfx, $exc, $ext);
   break;
 case ($phlen == 10):
   sscanf($ph, "%3s%3s%4s", $area, $pfx, $exc);
   break;
 case ($phlen == 11):
   sscanf($ph, "%1s%3s%3s%4s", $cty, $area, $pfx, $exc);
   break;
 case ($phlen > 11):
   sscanf($ph, "%1s%3s%3s%4s%s", $cty, $area, $pfx, $exc, $ext);
   break;
}

Looks more like a Lisper missing cond.

code:

(cond ((lt phlen 7) (setq ext ph))
      ((eq phlen 7) (sscanf ph "%3s%4s" pfx $exc))
      ((and (gt phlen 7) (lt phlen 10))
          (sscanf ph "%3s%4s%s" pfx exc ext))
      ((eq phlen 10) (sscanf ph "%3s%3s%4s" area pfx exc))
      ((eq phlen 11) (sscanf ph "%1s%3s%3s%4s" cty area pfx exc))
      ((gt phlen 11) (sscanf ph "%1s%3s%3s%4s%s" cty area pfx exc ext)))

Is what they seem to be looking for, assuming the existence of an sscanf macro in Lisp.

# ? Mar 30, 2008 13:09

nebby: Dec 21, 2000; resident mog

tef posted:

Now, what we are actually storing is a hash which uses student names as keys (strings) pointing to percentages (ints). This leads to the obvious naming scheme

Missed the point again chief, this would be something like mpNameSpct - a map (mp) from a name (a string containing a human readable name for display) and a Spct (a float containing a percentage that pertains to a particular kind of score.) Spct would be used throughout the code everywhere to talk about this particular quantity. If context wasn't obvious enough this was involving students, you'd call it mpNameSpctStudent. (And here you think I said context doesn't matter.) Do you still not get it? This is the opposite of encoding implementation.

"Score" is a lovely name for pretty much anything because every time I've written code involving scores there is more than one type of score. Passing these around becomes cumbersome and confusing to follow. For example, "public score" and "private score" and "human friendly score" and "score before we've added in bonus points" and so on. Sure I can look at 'context', but its funny because this exact case came up in the past for me, and deciphering what particular type of score was being calculated required going through lots of other methods for enough context to be sure. The places where this wasn't necessary was when the name was consistent like "publicScoreBeforeBonusPoints", which is precise and helped me a lot when it was used consistently, but is a mouthful. For all but the simplest projects, this dynamic happens with many different domain objects/quantities.

Now, the name mpNameSpct does encode implementation in part of the name, namely, "mp", which says it is a map (like a Hashtable or Dictionary.) You'd say this is bad, though. But look closely, because you've actually encoded that facet of implementation in your name, albeit less precisely, by making it plural. "StudentScores". By making it plural you've indicated it is some data structure that contains things. Not much beyond that. I'd argue that including the 'implementation' detail that it's a map and not a indexable list or something that's iterable at the cost of two characters at the beginning instead of one or two at the end is worth it, relevant, and not 'redundant'. The fact that English doesn't have a worthwhile suffix for describing "map vs. list" just shows how poorly English maps onto programming language variables. Now, Java interfaces get a nice mapping from English, the suffix "-able", but 'map vs. list' loses out.

You again forgot the main point of my post re: System vs Apps is that you fall back on encoding native type information when there is nothing else worthwhile to encode. For example, almost all booleans have an "f" prefix, because they are generally just used as a flag to check something. They're a goddamn boolean. Just because I use "f" for my boolean flag prefix all the time doesn't mean I am using "Systems Hungarian" because the rest of my code uses tags that encode far more than implementation (and much more than "Score".) This is less because "f" is useful and more because if we didn't put *some* tag at the beginning our names would appear inconsistent.

And again, the argument about context is missing the point. I have never said context isn't important, somehow you think context magically disappears if I am using Hungarian naming. Context is still just as useful and key to understanding an algorithm. But the goal is to optimize naming so you minimize the need for context. If this wasn't a worthwhile goal than we would name everything by typing random keys on the keyboard instead of trying to come up with something consistent and that makes sense. Just because my definition of "makes sense" grates against your bias towards English doesn't mean it's inferior on its own.

You also claim that the information encoded is "redundant". If you say "Score" and I say "Spct" which designates a specific domain specific type of score, I don't think it's redundant, but necessary, since there is no other place to directly encode that information other than in the amorphous context or comments of the method it is being used in.

I'm not a troll -- the points are subtle and your own self reflection of what you think that I am trying to get across reveals how they've flown over your head. I've read good arguments against this approach before, and yours is not one of them.

Edit: FYI

code:

class AppleBasket
    cApple = 0
    def addToBasket(basket)
        basket.cApple++
    def takeFromBasket(basket)
        basket.cApple--
    def cAppleInBasket(basket)
        return basket.cApple;

nebby fucked around with this message at 18:24 on Mar 30, 2008

# ? Mar 30, 2008 18:02

Victor: Jun 18, 2004

nebby, what if the programmers with whom you work just suck at giving proper context? Also, you repeatedly forget to note that this is much more important for dynamic languages, as things are less clear there. Have you looked into coding for the military, using ADA? It gets fairly close to your approach, but has compiler-enforced type safety. You can only get speed if you divide distance by time (or integrate acceleration by time, etc.).

Maybe I missed it, but I do not remember you ever explaining why your desire for Hungarian whatever is in the distinct minority of programmers. Does your approach really allow you to code more quickly and more accurately than other people, on average? (Take into account learning curve here!) To what extent are the problems you encounter, unique to your problem domain, or at least a very, very small fraction of programming?

The more I think about this, the more you must address the above if you want to stop digging/get out of the hole you've dug. Right now, you're some weird freak in most of our minds. I'm cutting you more slack than most, because I have very little respect for experience and track record, if I cannot understand the why behind the experience and track record. However, most people do, and you, my friend, have demonstrated zero.

# ? Mar 30, 2008 18:58

deimos: Nov 30, 2006; Forget it man this bat is whack, it's got poobrain!

quote:

Mode #cobol +b *!*@*.hu

# ? Mar 30, 2008 19:44

nebby: Dec 21, 2000; resident mog

Victor posted:

nebby, what if the programmers with whom you work just suck at giving proper context? Also, you repeatedly forget to note that this is much more important for dynamic languages, as things are less clear there. Have you looked into coding for the military, using ADA? It gets fairly close to your approach, but has compiler-enforced type safety. You can only get speed if you divide distance by time (or integrate acceleration by time, etc.).

Maybe I missed it, but I do not remember you ever explaining why your desire for Hungarian whatever is in the distinct minority of programmers. Does your approach really allow you to code more quickly and more accurately than other people, on average? (Take into account learning curve here!) To what extent are the problems you encounter, unique to your problem domain, or at least a very, very small fraction of programming?

The more I think about this, the more you must address the above if you want to stop digging/get out of the hole you've dug. Right now, you're some weird freak in most of our minds. I'm cutting you more slack than most, because I have very little respect for experience and track record, if I cannot understand the why behind the experience and track record. However, most people do, and you, my friend, have demonstrated zero.

Thanks for the sane voice. Sorry this is a derail, but I figured I should respond.

quote:

nebby, what if the programmers with whom you work just suck at giving proper context?

Could be. I know some of the code I've worked on recently (it was in Ruby) had a tendency to have lots of deeply nested data structures floating around with simple variable names. It took a debugger and manual tracing through the code to decipher the contents. Consistent naming and a lookup dictionary (like that prescribed by Hungarian) would have helped immensely.

However, I've also spent a lot of time digging through rails and other open source gems recently, and the problems there are patently obvious. Here's a tiny example. Yesterday I had to drill through some of Rails's template processing code. They pass variables with the name "template" around all over the place. My intuition totally fails me here -- this could contain the filename of the template, the name of the template, the HTML contents of the template, a parsed AST of the template, or a object of type Template (or something else.) The only way I can know is if I dig through all the dynamic crazy metaprogramming stuff, through methods that I have to figure out not based upon static binding but dynamic binding or method_missing calls, or get to a breakpoint in a debugger, or dig through unit tests. Wouldn't it be nicer if they just had a consistent understanding that "template" should always be a variable pointing to a Template object, and "htmlTemplate" and "astTemplate" and "fpthTemplate" and so on for the others? Of course, sometimes they'll say "template_file_name" or "template_contents" but its by no means a hard and fast rule, and it's generally not their fault because their approach in general does not encourage precision and typing those names out is just annoying.

Note that this problem still happens in static programming languages, replace "template" with "score" for an int variable and consider there may be many different types of scores, and the same problem comes through.

quote:

Have you looked into coding for the military, using ADA? It gets fairly close to your approach, but has compiler-enforced type safety.

I haven't looked into ADA much, but I know that a common argument in favor of Hungarian is that it is analogous to military acronyms or aviation acronyms. Instead of having to say a whole mouthful of poo poo when you want to talk about something precise you end up just saying a bunch of acronyms that sound like gibberish to an outsider. The reason it has evolved this way is because it was the best approach to providing precision in a realm where it was incredibly important and where just inventing new buzzwords quickly broke down since so many new terms were being used regularly.

quote:

Maybe I missed it, but I do not remember you ever explaining why your desire for Hungarian whatever is in the distinct minority of programmers.

I have, I think you missed it. Here it goes again. First, there is an aversion to reading it, because it usually lacks pronounceable words and appears as total gibberish to the untrained eye. It is painful to adapt to, on par with learning a new keyboard layout (something I've gone though

) .. much harder than learning a new programming language.

I think this is just another example of the classic case of intuitivity vs. efficiency. Most people, when they first start using something, do not even think about efficiency. If the system is intuitive, they pick it up quickly and stick to it, no matter how inefficient it is to use once they are experts. If you look at CAD systems they are notoriously unintuitive, and require years to get good at. But their user interfaces are incredibly efficient. This is an example where the tradeoff was recognized and a sacrifice was made in intuitivity for efficiency. At first glance, AutoCAD is totally impenetrable and if you just put a layman in front of it he will reject it for something that is more intuitive and matches what he is used to. But the pro can't live without it.

I see the push towards English naming as a consequence of this natural human desire for intuitivity. When you see a new piece of code, it is much easier for you to digest the overall algorithm if the names appear intuitive. However, if this is a body of code you need to become intimitely familiar with, in my experience, Hungarianized code is much easier to become efficient at working with, since there is less ambiguitiy once you penetrate the style of naming. Even once I became used to the overall concept of Hungarian, a new body of code with unrecognizable tags would seem menacing at first. But, provided the programmers involved were disciplined, after the initial pain of understanding what the hell was going on was passed (intuitivity was about zero) then I became a total domain expert for that body of code.

Additionally, Hungairian makes it painfully obvious what you do and don't understand. This was because you are not tricked into thinking you understand something because of it 'reading nicely'. You are forced to actually step through code mentally and truly grok what was happening. If you see an unrecognized tag, it signals "oh poo poo this is a big concept I haven't seen before", vs if you see a class called "Email" you think "eh, whatever, its some kind of email". These unfounded assumptions are dangerous and cause lots of bugs. It's all to easy to look at code examples in rails and ruby and miss the subtlety, simply because its easy to read.

Second, it has a bad reputation because of Systems Hungarian's prevalence in Win32 programming. Systems Hungarian is a total poison and it would be hard to think of a naming style that provides less value other than random characters.

quote:

Does your approach really allow you to code more quickly and more accurately than other people, on average? (Take into account learning curve here!) To what extent are the problems you encounter, unique to your problem domain, or at least a very, very small fraction of programming?

Well, I can't really point to empirical evidence, so I don't know how I can truly be convincing. What I will say, though, is that you do get a few clear benefits from Hungarian that are totally lacking in other approaches that probably lead to efficiency gains.

First, for writing code. You no longer "think of a name" for a variable. I can't stress this enough. I know from almost everyones perspective this seems trivial, but the amount of "numApples" vs "countOfApples" vs "appleCount" vs "applesInBasket" and so on I think really contributes to a lot of unnecessary noise both in reading and writing code.

When working on a team, each programmer often has their own unique style of naming. I'm sure you've all seen this. Some guy always has "retval" for the return value. Some guy always says "listOfApples" and the next guy says "apples" and the next guy says "listToReturn". Having everyone automatically agree that a list of apples is going to be "rgApple" makes it so your brain barely even registers the word, you just read it as you read this sentence and don't have to look at context to understand what I mean by the words I use.

I firmly think that the majority of creativity in programming should be spent on designing system architecture, data schema optimization, user interface design and other tasks that directly impact the success or failure of a given project. In my own personal experience, in projects where we were not using Hungarian, a disproportionate amount of creative energy was spent on coming up with names that best mapped the purpose of a type onto an English real-world equivalent. All this effort, pining over if we should call something the "EmailDispatch" or the "EmailSender", and so on. Again, it seems trivial, but totally removing this creative burden once we decided a name was really not that important was very liberating. On small projects, this is no big deal. But when you start building huge class libraries you end up getting lots of "English collisions" and end up twisting the language in directions it was never meant to go. A simple reporting framework explodes into having things called ExtendedSearchSiteReportsEmailReport (a real example.)

Edit: Oh, and before someone says "namespaces" here, let me remind you that namespaces are a compiler hack for binding names to classes and not meant to reduce ambiguity in the name itself.

quote:

To what extent are the problems you encounter, unique to your problem domain, or at least a very, very small fraction of programming?

I've worked on two projects with Hungarian, one was for ISC as you guys probably all know now, and one is my own. So, I can't really make an argument for or against its success on those projects in terms of it being universal. I will say that I am working on educational software, particularly within scheduling, and not having to come up with fancy names for all the different actors involved in a schedule is incredibly nice. If I had to, my code would be riddled with "TimeBlockCategory" "TimeBlock" "LearningGroup" "LearningSession" and all these things which really end up having no real English equivalent. I've found that writing parsers for schedule data has been incredibly easy since the code is incredibly dense for these parsers but I never find myself grasping at straws for a good name. Hungarian provides a mental framework for me to come up with patterns of names that might be very domain specific but end up being consistent. I am fairly confident that other developers will be able to understand *all* the parsers I write, despite the fact that upon first glance they look intimidating, since its just a matter of understanding the language.

That said, I draw a lot of my conclusions not based upon the projects I've been using Hungarian with, but the contrast against the projects I've worked on without it over the years. I remember distinctly arguing over what we should call things and tracing through code trying to find enough context to understand what exactly was being stored in a quantity. Knowing the type of a variable through IntelliSense is often not enough to get at the crux of its role in an algorithm, so the applicability of this to static languages is still very useful. (Though I'll grant it's been even more profound for me in Ruby.)

nebby fucked around with this message at 20:32 on Mar 30, 2008

# ? Mar 30, 2008 20:01

Z-Bo: Jul 2, 2005; more like z-butt

nebby posted:

Yeah, I mean, I catch myself using "i" when I know better. The problem is, I see it as a bad habit when most see it as acceptable. When you are writing a loop, you can quickly get into trouble if you have nested loops and have i, j, or even k being used. Additionally, and more importantly, using "i" is ignoring an opportunity to introduce a good name into the code. You're looping over it for a reason, so you should usually opt to provide hints as to why you're doing so in the name. If you are looping over a list of apples that need to be put into another bucket, instead of "i", you could use "iAppleForBucket" and not worry about confusing it with another loop variable and potentially remove a comment saying "// We loop over the apples for the bucket" !

This is why I think you are missing the point of Intentional Programming.

As I understood it from Simonyi's explanation, the mere notion that you loop over apples in a bucket has one more parameter than is necessary: you are creating an index for something that inherently has no necessary index. There is no need to create a key, because all the key does is provide base address plus offset. In other words, all it does is provide information about what is in a particular memory address.

Furthermore, this is a general idea in Computer Science that was made obvious by Ted Codd: set-based programming is superior to Bachman-style navigational programming. The for loop and the nested loop patterns are artifacts from navigational programming. Some people were really stunned when Codd showed that math could be used to provide succinct code.

nebby posted:

I don't see how I can be misrepresenting them when the lead dev at Simonyi's company (who is a real wizard, IMHO) told me my blog put forward the best argument he had ever read for Hungarian (assumingly apart from those written by Charles.)

You are using an appeal to authority to back up your point. Yet, you aren't telling me why that person thought your argument was worth hearing. I don't care if they liked it or hated it. I care that they understood it and why they would recommend I read it.

I have read ISC devs' blog comments on some of Simonyi's staff on his blog, and they were always impossible to understand. It was all blah, blah, blah, THEN I HAD AN EPIPHANY, blah, blah, blah. This is how you come across, as well. By contrast, Simonyi is the only person at that company who really wows me with their comprehension about this idea of "Intentional Programming".

# ? Mar 30, 2008 20:25

Z-Bo: Jul 2, 2005; more like z-butt

nebby posted:

code:

class AppleBasket
    cApple = 0
    def addToBasket(basket)
        basket.cApple++
    def takeFromBasket(basket)
        basket.cApple--
    def cAppleInBasket(basket)
        return basket.cApple;

This interface doesn't make any sense. Why would you add a basket to a basket?

The most important parameter to explicitly model in this problem is that you clearly care about ownership and not membership. These baskets are not the same thing as mathematical sets, so you cannot therefore model them as sets: you cannot use membership as a status. One basket must clearly own all of the apples in its basket. Forget the fact you have the "c" in there. Your model is dumb. You have bigger problems than whether to use Hungarian notation or not!

# ? Mar 30, 2008 20:33

nebby: Dec 21, 2000; resident mog

Z-Bo posted:

This is why I think you are missing the point of Intentional Programming.

I've said it before: Hungarian notation is a suboptimal solution to the larger problem of encoding programmer intent in a name. And that, having to name variables and write code, is a suboptimal solution to the larger problem of providing programmers and domain experts with the best means of describing their problems in a way that a computer can solve them.

You're right, index variables are unnecessary mathematically, but in some languages (which I deemed "sane", a misnomer perhaps) we are forced to use them. When we are forced to use them, the question of naming comes into play. When the question of naming comes into play, we are forced into coming up with one that usually matches /^[A-Z][0-9A-Z]*/i that's less than some maximum length. It's this set of constraints that Hungarian is designed (again, forced) to work within. Think of it as an incredibly 'projected' view of the ideal solution to a specific subproblem onto the lovely tools and languages we have forced upon us today.

quote:

You are using an appeal to authority to back up your point.

No, it's not an appeal to authority when you say I am misrepresenting someone when someone working directly with that person says I am representing them accurately. You weren't questioning the content of my argument, you were questioning my 'representation of Simonyi's view' without giving me specific of why you felt I was doing so. So, all I could do is tell you that people who have an intimate understanding of this view don't agree.

As far as the specifics, I mean, basically it was like "good job on that post I think you hit the points on Hungarian better than anyone has written before" or something like that? If you have any other specific things you think I am not making sense about then you have to admit I've been more than willing to try and refute them, don't go painting me like I am some question dodging illogical person.

# ? Mar 30, 2008 20:48

hey mom its 420: May 12, 2007

nebby's example looks like it's written in Python and there, the first argument to a method is always the instance itself. So if you have

code:

>>> class Boo:
...   def store_this(self, str):
...     self.my_str = str
>>> b = Boo()
>>> b.store_this('haha')
>>> b.my_str
'haha'

But anyway, the first parameter of instance methods in Python should always be called self. This is a very, very strong convention and Guido would probably have a heart attack if he saw anyone using anything other than self as the first parameter to instance methods.

# ? Mar 30, 2008 20:52

nebby: Dec 21, 2000; resident mog

Z-Bo posted:

This interface doesn't make any sense. Why would you add a basket to a basket?

The most important parameter to explicitly model in this problem is that you clearly care about ownership and not membership. These baskets are not the same thing as mathematical sets, so you cannot therefore model them as sets: you cannot use membership as a status. One basket must clearly own all of the apples in its basket. Forget the fact you have the "c" in there. Your model is dumb. You have bigger problems than whether to use Hungarian notation or not!

What the gently caress are you talking about? This was someone elses example and I just renamed all the constants in his example to be consistent with how I would name them in the same model. The fact you are assuming anything about baskets, apples, and so on, (they're 'not the same thing as ... sets', we care about 'ownership' not 'membership') is really confusing.

Again, your bias towards English is making you assume something about what I mean when I say "addToBasket(basket)". In his example, he (bizarrely) passed in a reference to a basket to add one to the count. I'm assuming in this bizzaro example this fake language we are programming in those are static methods, otherwise passing in a basket would make no sense. In Hungarian, its "<returnType><verb><parameters>" so I am not returning anything, I am addingTo, and I am passing it a basket. Implicit is the fact that the verb "addTo" will increase the count of apples ("cApple") on the specified basket.

If I was going to pass an apple into the basket to add to it, it would be "addApple(apple)".

Oh poo poo. I just typed this reply up, and realized the reason we are both confused in the first place is because his naming sucked in the original example. In his 'unenlightened programmer' he passed in a variable called "s", which I guess he meant to be an Apple not a Basket. But then in his 'enlightened' example, he passed in something called "applebasketself" which I assumed was the basket he wanted to increment the count of apples on. He actually confused himself by his own lovely naming, unless I am missing something.

Double oh poo poo. Ok, so that was a reference that is supposed to be self, and we're in Python. Now I get it. I think instead of him confusing himself, he confused Z-Bo, who thought we were passing in Apples instead of it being the self variable. With this in mind, I would have named my methods "add" and "take" since we would not include the Basket in the name since it's an implicit parameter (self).

I think the important thing to take away from this is that all this confusion stems from bad and ambiguous names. If he called his first parameter "self", it would have been fine since we all understand what that means. Also, consider these three method names: "add", "addApple", "addToBasket". With Hungarian, I can tell you exactly what the inputs and outputs of these are, and while I can't tell you *exactly* what they do, I will be much less confused than if there were no rules for me to think of when I saw these methods.

nebby fucked around with this message at 21:19 on Mar 30, 2008

# ? Mar 30, 2008 20:56

nebby: Dec 21, 2000; resident mog

Ok, my g/f just came over and said she saw "the penis man" (my avatar) and so that means I'm slacking off and posting and I should stop. She's right, and I am, so back to your regularly scheduled programming (Z-Bo you get the last word

)

# ? Mar 30, 2008 21:10

Zombywuf: Mar 29, 2008

There's nothing wrong with Hungarian Notation used judiciously, but there's a lot wrong with using it everywhere. It suggests something going badly wrong with your code. Nebby, your examples sound like the code your working on makes poor use of scoping. The problem you think Hungarian Notation solves, I would say, is much better solved by making sure your names stay within about half a page of each other. That is, don't let your functions get so big that the entire context of the name is visible on the screen. If this is impossible, class members for example, the names should be maximally descriptive.

This seems to be the point where you struggle, 'apples' is almost always going to be a collection of 'apple' objects, we don't need to tack on 'lst', 'vec' etc to the beginning to tell us this (yes this is an oblique example of Hungarian Notation, however, it's also English). If all else fails you can just go look them up (C-r in my editor). If your class gains so many members it's impossible to keep track of them all in your head then you need to refactor your class, not rename the members. This is why Hungarian everywhere is a bad sign for code, it's the wrong solution to the problem of complexity.

# ? Mar 30, 2008 21:24

rotor: Jun 11, 2001; classic case of pineapple derangement syndrome

I think I've spent more time reading nebby posts about hungarian than I've spent, total over the 12 years I've been a programmer, being confused by variable names.

Nebby, do you have any kind of studies that show this to be any kind of significant problem at all? Honestly, the entire argument reeks of brace-style, tabs-vs-spaces nonsense, except everyone seems to be taking it seriously, which baffles me.

# ? Mar 30, 2008 22:59

nebby: Dec 21, 2000; resident mog

rotor posted:

Nebby, do you have any kind of studies that show this to be any kind of significant problem at all? Honestly, the entire argument reeks of brace-style, tabs-vs-spaces nonsense, except everyone seems to be taking it seriously, which baffles me.

No, how could I? The whole thing has been largely ignored and discarded by the programming community, who would study it? It had its hayday when it was in the win32 API, as Systems, and got totally discredited and labelled as a "bad idea." Honestly, it's not a huge issue to me these days, I just am often amazed at the reaction I get when it comes up and the logical fallacies otherwise smart people start throwing out there, so it's something I get sucked into in threads like this. I can switch away from it somewhat easily, but it can be painful. It's kind of like the pain I get when I realize I know I am not writing enough unit tests

I mean, think about it. Many people in this forum think I'm some crazy person, a troll, a kook, a crackpot, throw personal insults and so on because of a variable naming convention I promote when I write computer programs. It's ridiculous. I certainly don't think about anyone here in that way, regardless of whatever they might post in a thread!

# ? Mar 30, 2008 23:31

rotor: Jun 11, 2001; classic case of pineapple derangement syndrome

nebby posted:

No, how could I? The whole thing has been largely ignored and discarded by the programming community, who would study it?

I dunno. Given the number of grad students in the world, I find it hard to believe that there's been zero studies done.

quote:

Honestly, it's not a huge issue to me these days, I just am often amazed at the reaction I get when it comes up and the logical fallacies otherwise smart people start throwing out there

If you have a bunch of 'otherwise smart people' who routinely tell you you're crazy whenever you bring this up, you should probably take a step back and consider whether:

(a) you are not communicating your ideas well enough, because all these otherwise smart people are just not getting it or

(b) you are in fact crazy

That's just honest feedback, man. Do with it what you will.

quote:

I mean, think about it. Many people in this forum think I'm some crazy person, a troll, a kook, a crackpot, throw personal insults and so on because of a variable naming convention I promote when I write computer programs.

Well, it's a software forum. We kind of take software seriously here. I don't really care what you're like as a human being, but so far all your opinions on writing software I've seen are ... well, they're crazy. As for the personal insults, I dunno man, welcome to SA I guess.

# ? Mar 30, 2008 23:43

Allie: Jan 17, 2004

rotor posted:

I think I've spent more time reading nebby posts about hungarian than I've spent, total over the 12 years I've been a programmer, being confused by variable names.

Nebby, do you have any kind of studies that show this to be any kind of significant problem at all? Honestly, the entire argument reeks of brace-style, tabs-vs-spaces nonsense, except everyone seems to be taking it seriously, which baffles me.

I'm not sure what the gently caress he's talking about either, but I think tef nailed it with his fake quote. It almost seems like nebby agrees that Hungarian is confusing line noise, but that when you parse all that useless information it all magically clicks and you enter this zen buddha mode of coding and all the code suddenly makes sense.

At least that's what I've gathered from his points.

# ? Mar 30, 2008 23:46

biznatchio: Mar 31, 2001; Buglord

Well I think sheds should be painted blue.

# ? Mar 30, 2008 23:51

nebby: Dec 21, 2000; resident mog

rotor posted:

If you have a bunch of 'otherwise smart people' who routinely tell you you're crazy whenever you bring this up, you should probably take a step back and consider whether:

My last job everyone hated the idea of Hungarian for the first two months, told me I was crazy. By the 4th month one or two were actually actively pro-Hungarian, about half saw the merits and agreed, and everyone I think agreed that their initial impression at least was off. The DBA thought it was retarded, though

So, initial reactions for something like this are not indicative of how people feel once they've put it into practice. Beyond that, just talking about it on a forum isn't really effective at convincing people, so it's kind of stupid for me to be doing so. It's really a 'do it and see how you feel in a few months' type of thing. It's like switching OS'es, from automatic to stick, languages, like anything really, where at first you're like "man this sucks" but eventually its no big deal. For example, I loving loathed ActiveRecord when I first used it, and still think it pretty much sucks, but don't spend afternoons writing tirades on it anymore.

quote:

Well, it's a software forum. We kind of take software seriously here. I don't really care what you're like as a human being, but so far all your opinions on writing software I've seen are ... well, they're crazy. As for the personal insults, I dunno man, welcome to SA I guess.

Er, go ahead and name some of my other opinions you find crazy! I've posted in threads on TDD, rails, OOP, design patterns, web services, C#, SQL, and other random poo poo here and I don't think anyone has been like "hey its that crazy guy!" since my posts are more in line with 'sanity' and until I had the dude with the crotch over to the left there nobody even knew who I was.

As for SA, yeah, well, I've been here forever so I know how it goes. It's still dumb though, but I guess programmers are known for crucifying each other over editor choices and such.

nebby fucked around with this message at 23:54 on Mar 30, 2008

# ? Mar 30, 2008 23:52

defmacro: Sep 27, 2005; cacio e ping pong

biznatchio posted:

Well I think sheds should be painted blue.

You would you goddamn hippie.

# ? Mar 31, 2008 00:01

Z-Bo: Jul 2, 2005; more like z-butt

biznatchio posted:

Well I think sheds should be painted blue.

A blue shed will survive a nuclear holocaust in the event the power plant nukes itself. When someone looks at the blueprints for this facility 10,000 years from now after the radioactivity has decayed, people will look at it and recognize it is a blue shed.

# ? Mar 31, 2008 00:13

deimos: Nov 30, 2006; Forget it man this bat is whack, it's got poobrain!

Z-Bo posted:

A blue shed will survive a nuclear holocaust in the event the power plant nukes itself. When someone looks at the blueprints for this facility 10,000 years from now after the radioactivity has decayed, people will look at it and recognize it is a blue shed.

not enough namedropping in this post.

# ? Mar 31, 2008 00:33

tef: May 30, 2004; -> some l-system crap ->

Dear nebby, victor, zbo:

drat kids get out my thread :argh:

If you really wish to beat this dead horse go and start a new thread so we can go back to making fun of crap code.

# ? Mar 31, 2008 10:13

hey mom its 420: May 12, 2007

Ultimate variable naming scheme

code:

private static int :iamafag: (String :buddy:, int :D) {
            // ... code here
}

# ? Mar 31, 2008 15:13

Flobbster: Feb 17, 2005; "Cadet Kirk, after the way you cheated on the Kobayashi Maru test I oughta punch you in tha face!"

Bonus posted:

Ultimate variable naming scheme

code:

private static int :iamafag: (String :buddy:, int :D) {
            // ... code here
}

Similarly, back when C# first came out, I couldn't resist the urge to use full Unicode in my identifier names.

code:

float &#960; = 3.14159;
int &#916;x = xCurr - xPrev;
object &#12371;&#12428; = this;

I never did this in any serious projects, but it was tempting.

On the one hand, I think having the ability to use Unicode identifiers is awesome and long overdue. On the other hand, it would permit sweet revenge and job security for those outsourced overseas programmers to write all their code in Hindi or Urdu character sets :gonk:

# ? Mar 31, 2008 15:32

Victor: Jun 18, 2004

I don't think we should stop at making programmers manage their own type systems in symbol names. I think they should have to code in assembly. Screw that: ones and zeros. Actually, what would happen if we made programmers code mechanically, maybe via some sort of punch card system that is about as reliable as the punch cards used in the Florida election? Surely, in that case, the bug count would go way down.

# ? Mar 31, 2008 16:22

narbsy: Jun 2, 2007

Victor, you are thinking too advanced.

The only way to program is to create an analytical machine in the form of a difference engine to do it for you!

No need for messy punch cards, only pure determination and genius. Lots of genius. I'd love to see dynamic programming on one of these babies. Also, far less writing and punching than cards.

# ? Mar 31, 2008 16:26

tef: May 30, 2004; -> some l-system crap ->

If we're going into unicode territory how about something like ∀ x ∈ l : print x; perhaps?

# ? Mar 31, 2008 16:36

Zombywuf: Mar 29, 2008

tef posted:

If we're going into unicode territory how about something like ∀ x ∈ l : print x; perhaps?

Wouldn't that make the existential operator the perfect mechanism to introduce unification and backtracking into a language?

ps.
#define ∀(col, op) for_each(col.begin(), col.end(), op)

# ? Mar 31, 2008 16:48

rotor: Jun 11, 2001; classic case of pineapple derangement syndrome

tef posted:

If we're going into unicode territory how about something like ∀ x ∈ l : print x; perhaps?

We're gonna need bigger keyboards.

# ? Mar 31, 2008 17:03

Flobbster: Feb 17, 2005; "Cadet Kirk, after the way you cheated on the Kobayashi Maru test I oughta punch you in tha face!"

rotor posted:

We're gonna need bigger keyboards.

APL was ahead of its time! It was a language without a mainstream character set large enough to hold it... but now things are different!

It's ripe to make a comeback, I say!

# ? Mar 31, 2008 17:10

zootm: Aug 8, 2006; We used to be better friends.

tef posted:

If we're going into unicode territory how about something like ∀ x ∈ l : print x; perhaps?

Been using Fortress, have we?

# ? Mar 31, 2008 17:28

Victor: Jun 18, 2004

rotor posted:

We're gonna need bigger keyboards.

Apparently it's about as hard to go Hungarian (^_{_System} Apps) as to learn a new keyboard layout, so this might not be a half bad idea!

# ? Mar 31, 2008 17:36

tef: May 30, 2004; -> some l-system crap ->

rotor posted:

We're gonna need bigger keyboards.

This do?

# ? Mar 31, 2008 17:55

rotor: Jun 11, 2001; classic case of pineapple derangement syndrome

tef posted:

This do?

look at the hosed-up brace and arrow key placement, I can't use that piece of poo poo.

rotor fucked around with this message at 18:30 on Mar 31, 2008

# ? Mar 31, 2008 18:15

npe: Oct 15, 2004

tef posted:

This do?

Is there a das keyboard version?

# ? Mar 31, 2008 18:28

Victor: Jun 18, 2004

yaoi prophet posted:

Is there a das keyboard version?

gently caress that, I want an OLED version.

# ? Mar 31, 2008 18:30

Adbot: ADBOT LOVES YOU

# ? Apr 26, 2024 05:48

Triple Tech: Jul 28, 2006; So what, are you quitting to join Homo Explosion?

These things, as Perl programmer, piss me off:

code:

@stack = ();
for ($i = 0; $i < scalar @elements; $i++) {
  $temporary = do_something_to $elements[$i];

  push @stack, $temporary;
}

It's abundantly clear this person doesn't know about scope, the context-sensitive return value of an array, foreach loops, and map. God drat.

code:

print HANDLE "This one also demonstrates something else.";
print HANDLE "This programmer doesn't know how to use select.";
print HANDLE "Nor does he know what a heredoc is.";
print HANDLE "You get paragraphs of text that look like this.";
print HANDLE "For no reason, really.";

Point is, for you non-Perl folk, is that this poo poo could have been written in a more concise, more native-to-Perl fashion.

# ? Mar 31, 2008 18:44

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Coding Horrors: You can gather all your technical debt into one easy framework!

«‹›1501 »