Your secret tips in code

  • (2 Pages)
  • +
  • 1
  • 2

24 Replies - 2156 Views - Last Post: 06 September 2012 - 06:36 AM

#16 Lemur  Icon User is offline

  • Pragmatism over Dogma
  • member icon


Reputation: 1368
  • View blog
  • Posts: 3,455
  • Joined: 28-November 09

Re: Your secret tips in code

Posted 31 August 2012 - 09:45 PM

That brings up another point of mine: ALWAYS know at least one level of abstraction below what is necessary for your job. If you write Java, learn C, if you write C, learn Assembly, if you write Assembly, God help you.

This helps you to understand more of the inner workings of the language you work in, and helps to clarify some elements that might have formerly been taken for granted.

I've been told that LISP is a must learn on multiple occasions. Considering some of its tenants and strengths, I'm inclined to agree. It forces you into entirely different ways of thinking, most of which have a dramatic effect on the way you see code. I wouldn't hesitate to call it something of an enlightenment.
Was This Post Helpful? 3
  • +
  • -

#17 jon.kiparsky  Icon User is online

  • Pancakes!
  • member icon


Reputation: 7757
  • View blog
  • Posts: 13,121
  • Joined: 19-March 11

Re: Your secret tips in code

Posted 31 August 2012 - 10:56 PM

Quote

ALWAYS know at least one level of abstraction below what is necessary for your job.


That's certainly a great piece of advice - one I give often and wish I followed a lot more. :)

Learning Lisp is certainly good for the brain. It's weird at first, but when you start to get it, a lot of it starts to seem very obvious and intuitive. The trouble is, you start wishing every language was more like lisp. The good part is, you start learning ways to do things in lisp style in other languages, so it makes your code better.
Was This Post Helpful? 0
  • +
  • -

#18 cfoley  Icon User is offline

  • Cabbage
  • member icon

Reputation: 2002
  • View blog
  • Posts: 4,162
  • Joined: 11-December 07

Re: Your secret tips in code

Posted 03 September 2012 - 07:43 AM

Quote

I like to start all arrays at 1 and reserve the 0'th element for temp holding.


I pity the poor soul who has to decipher your code!
Was This Post Helpful? 3
  • +
  • -

#19 AdamSpeight2008  Icon User is offline

  • MrCupOfT
  • member icon


Reputation: 2263
  • View blog
  • Posts: 9,467
  • Joined: 29-May 08

Re: Your secret tips in code

Posted 03 September 2012 - 08:46 AM

View PostRhymer, on 30 August 2012 - 07:05 PM, said:

I like to start all arrays at 1 and reserve the 0'th element for temp holding.


Automatically ruling out you using LINQ or PPL, which assume a 0-based collection.

The caching can abstracted out into it own generic wrapper object.


Set up a NuGet package library on your system.
Then create useful DLLs and import them into you projects.
Use Extension methods (especially generic ones), they can make your code a hell of a lot easier to write and read.
Split up your project into smaller sub-projects. (Interfaces, Base-Classes, Classes, Core, GUI, Application.)
Was This Post Helpful? 1
  • +
  • -

#20 The Architect 2.0  Icon User is offline

  • D.I.C Regular

Reputation: 37
  • View blog
  • Posts: 351
  • Joined: 22-May 08

Re: Your secret tips in code

Posted 03 September 2012 - 11:45 PM

View Postjon.kiparsky, on 31 August 2012 - 09:56 PM, said:

It's not a question I'd ask, at least not that way, but I can see why someone might ask it.


I see what you mean there.

I just wish the interviewers wouldn't put so much emphasis on you remembering all the edge cases for the whole series of sort algorithms and data structures. It's exceptionally painful for me to see an HR person mark me as 'wrong' just because my code wasn't nearly similar enough to their example.

...then again...I think nearly all tests are stupid /reminded of high school chemistry tests where we weren't allowed to use a periodic table
Was This Post Helpful? 0
  • +
  • -

#21 cfoley  Icon User is offline

  • Cabbage
  • member icon

Reputation: 2002
  • View blog
  • Posts: 4,162
  • Joined: 11-December 07

Re: Your secret tips in code

Posted 04 September 2012 - 01:25 AM

View Postcfoley, on 03 September 2012 - 03:43 PM, said:

Quote

I like to start all arrays at 1 and reserve the 0'th element for temp holding.


I pity the poor soul who has to decipher your code!


To elaborate, nobody expects code to work like this and it would probably take a while to realise the intent behind such a piece of code. Instead you can make everything clear by just declaring a temp variable. You can also keep it tidy by keeping the temp variable in local scope. It also keeps things consistent for the times when you need two temp variables and it allows you to name them more descriptively.

As a bonus, arrays are supposed to be zero-indexed in most languages and you could be missing out on a load of features that would make your life easier. AdamSpeight2008 listed a few for the .NET world and for..each springs to mind as a more general candidate.

With sorting, it depends on the size of the data, how it is stored (array, linked list, other ADT or in a file system), whether the sort has to be stable, the anticipated initial distribution of the items and the required performance. For most uses, you would be crazy to use anything other than the sorting procedure provided by the language.
Was This Post Helpful? 2
  • +
  • -

#22 Skydiver  Icon User is offline

  • Code herder
  • member icon

Reputation: 3576
  • View blog
  • Posts: 11,125
  • Joined: 05-May 12

Re: Your secret tips in code

Posted 04 September 2012 - 03:14 AM

On the topic of rewriting system libraries, I remember that in the late 80's through the mid 90's, a lot of people didn't trust or like the way malloc() and/or operator new were implemented and people would write their own memory management. Or if they didn't implement their own schemes, they would wrap the library routines so that they could perform logging to check for memory leaks, as well as some basic buffer overrun checks. I don't hear about this happening as much in the 2000's and 2010's, except for a few tips in one or two of the Game Programming Gems books.

Do people now trust their system libraries to have efficient memory allocation? Or is memory now a much more abundant resource that people are not quite as paranoid about it? Does the availability of static and dynamic memory analysis tools now take away the need to roll your own memory allocation logging?
Was This Post Helpful? 0
  • +
  • -

#23 jon.kiparsky  Icon User is online

  • Pancakes!
  • member icon


Reputation: 7757
  • View blog
  • Posts: 13,121
  • Joined: 19-March 11

Re: Your secret tips in code

Posted 04 September 2012 - 06:15 AM

View PostSkydiver, on 04 September 2012 - 05:14 AM, said:

On the topic of rewriting system libraries, I remember that in the late 80's through the mid 90's, a lot of people didn't trust or like the way malloc() and/or operator new were implemented and people would write their own memory management. Or if they didn't implement their own schemes, they would wrap the library routines so that they could perform logging to check for memory leaks, as well as some basic buffer overrun checks. I don't hear about this happening as much in the 2000's and 2010's, except for a few tips in one or two of the Game Programming Gems books.

Do people now trust their system libraries to have efficient memory allocation? Or is memory now a much more abundant resource that people are not quite as paranoid about it? Does the availability of static and dynamic memory analysis tools now take away the need to roll your own memory allocation logging?


I think a lot of that was a product of proprietary compilers and libraries (thinking specifically of C, since you mention malloc). Since the internals were not visible, and there were known issues, there was a lot of rewriting, much of it rational, some of it for purposes of voodoo and hoodoo. That is, some people would have seen real issues and written local solutions for those issues, which would have remained locked away as company property. Some people would have rewritten libraries out of a sort of cargo-cult motivation, because that's what they saw other people doing, with greater or lesser understanding of the reasons for it. And others would have made their own local libraries because it made them seem more elevated in the eyes of the lesser coders surrounding them, regardless of whether their versions were improvements on or degenerations of the original. "There's Bob, he's so smart he rewrote all of the standard libraries, so we #include <bobio.h> here". (nobody was supposed to ask why bob was getting paid to re-write existing code, and how this created value for Bob's employer)

Under the gcc it was possible to see the issues and address them, and for the fixes to propagate back to the source, meaning each problem only had to be solved once. This means that there's a lot less by way of plausible justification floating around for establishing a local wheel-design shop in each company.
Was This Post Helpful? 0
  • +
  • -

#24 jon.kiparsky  Icon User is online

  • Pancakes!
  • member icon


Reputation: 7757
  • View blog
  • Posts: 13,121
  • Joined: 19-March 11

Re: Your secret tips in code

Posted 05 September 2012 - 10:22 PM

View PostThe Architect 2.0, on 04 September 2012 - 01:45 AM, said:

I just wish the interviewers wouldn't put so much emphasis on you remembering all the edge cases for the whole series of sort algorithms and data structures. It's exceptionally painful for me to see an HR person mark me as 'wrong' just because my code wasn't nearly similar enough to their example.


Remember, the interview goes both ways. If you're not impressed with the person interviewing you, maybe it's not the place for you.
Was This Post Helpful? 1
  • +
  • -

#25 baavgai  Icon User is offline

  • Dreaming Coder
  • member icon

Reputation: 5833
  • View blog
  • Posts: 12,687
  • Joined: 16-October 07

Re: Your secret tips in code

Posted 06 September 2012 - 06:36 AM

Biggest tip, write for a stranger. Always assume that some poor bugger is going to have to deal with your code when you aren't there. In six months to a year, you could be that stranger. "WTF was this idiot thinking?!? Oh, that's mine."

Clear is far more helpful than clever.

Building the killer reusable framework of doom a siren's call best ignored. You will be tempted, but such activities, more often than not, add more complexity than clarity. I read an astute observation of this phenomena recently: Truth no. 3: Too many senior developers spoil the code

The newest toy is rarely the best toy. Ignore hype. However, you must know how the new toys work before you pass judgement.

Interfaces! The more OO work I do, the more I agree James Gosling on interfaces vs. classes, or "Why extends is evil". This is kind of a modern software development trend, interfacing everything and injecting functionality. You can already see it being overused. However, in many places it is an excellent sanity check.

View PostRhymer, on 30 August 2012 - 02:05 PM, said:

I like to start all arrays at 1 and reserve the 0'th element for temp holding.


If I had to maintain this code, I would track you down and beat you. Either before or after I had to totally rewrite it.
Was This Post Helpful? 2
  • +
  • -

  • (2 Pages)
  • +
  • 1
  • 2