26 Reply by bahstrike

  • bahstrike
  • Member
  • Offline
  • Registered: 2012-09-27
  • Posts: 57

Re: Week 1 Solidoodle II Print Challenge (double helix)

I'm poking around slic3r source and I can tell you it's a lot better than some $1M priced code I've had the 'pleasure' of working with.

He's doing a good job splitting a subroutine's internals with whitespace and usually putting a little comment for each one that briefly states the operation about to be done. It's a bit like reading a little story  smile   You'd be surprised how rare this can be in novice OR production code.  It would be pretty easy to jump in and start making modifications because it's organized fairly nicely.

Never used perl  (nor had reason to.... until now?)  but I must say I'm getting a kick out of the  'my' and 'our' keywords.
I'll be hacking around this stuff when I get my printer

27 Reply by solijohn

  • solijohn
  • Member
  • Offline
  • Registered: 2012-08-07
  • Posts: 1,465

Re: Week 1 Solidoodle II Print Challenge (double helix)

bahstrike wrote:

I'm poking around slic3r source and I can tell you it's a lot better than some $1M priced code I've had the 'pleasure' of working with.

He's doing a good job splitting a subroutine's internals with whitespace and usually putting a little comment for each one that briefly states the operation about to be done. It's a bit like reading a little story  smile   You'd be surprised how rare this can be in novice OR production code.  It would be pretty easy to jump in and start making modifications because it's organized fairly nicely.

Never used perl  (nor had reason to.... until now?)  but I must say I'm getting a kick out of the  'my' and 'our' keywords.
I'll be hacking around this stuff when I get my printer

I've never understood why novice coders refuse to comment code. It seems quite natural to do in all situations.
My experience with the code was trying to find where the defaults were stored. In Pronterface these defaults are quite easy to find (and modify for the Solidoodle's unique temperature requirements.) I've asked the dev a few times to help me find them, but he seemed more concerned with trying to sell us consulting. I'm sure I've passed them by a hundred times - just didn't know where to look.

Not that I've been able to devote hours to decoding things.

Former Solidoodle employee, no longer associated with the company.

28 Reply by zimmer62

  • zimmer62
  • Member
  • Offline
  • Registered: 2012-08-10
  • Posts: 163

Re: Week 1 Solidoodle II Print Challenge (double helix)

solidoodlesupport wrote:

I've never understood why novice coders refuse to comment code. It seems quite natural to do in all situations.
My experience with the code was trying to find where the defaults were stored. In Pronterface these defaults are quite easy to find (and modify for the Solidoodle's unique temperature requirements.) I've asked the dev a few times to help me find them, but he seemed more concerned with trying to sell us consulting. I'm sure I've passed them by a hundred times - just didn't know where to look.

Not that I've been able to devote hours to decoding things.

As a programmer for a living, really good clean code needs no comments at all.  It literally tells you exactly what it's doing.  (This is always a hot topic for programmers)

Read the book by Bob Martin called "Clean Code" and you'll see there is a lot a programmer can do to write good SOLID (yes that is a programming acronym) code that is easy to read, and easy to maintain with very few if any at all comments.

When I see a section of code that has more comments than code it smells funny.  Comments can lie about what that block of code is doing anyways.

If you keep the cyclomatic complexity down and follow the single responsibility principle, using well named methods and variables you just don't need comments since they are usually redundant.

Being novice has nothing to do with why a coder does or doesn't comment their code.  And uncommented code has very little proof that coder is a novice or not.  A novice usually writes a lot more code than is needed, it smells funny, has high cyclomatic complexity, lacks the use of design patterns, and is usually a nightmare to maintain. 

I didn't look at slic3r's code so I can't tell you if it's sloppy code or not, you're right that perl is a little vague in general which is why I'd never use it for a larger project that will grow and grow over time.

29 Reply by solijohn

  • solijohn
  • Member
  • Offline
  • Registered: 2012-08-07
  • Posts: 1,465

Re: Week 1 Solidoodle II Print Challenge (double helix)

zimmer62 wrote:
solidoodlesupport wrote:

I've never understood why novice coders refuse to comment code. It seems quite natural to do in all situations.
My experience with the code was trying to find where the defaults were stored. In Pronterface these defaults are quite easy to find (and modify for the Solidoodle's unique temperature requirements.) I've asked the dev a few times to help me find them, but he seemed more concerned with trying to sell us consulting. I'm sure I've passed them by a hundred times - just didn't know where to look.

Not that I've been able to devote hours to decoding things.

As a programmer for a living, really good clean code needs no comments at all.  It literally tells you exactly what it's doing.  (This is always a hot topic for programmers)

Read the book by Bob Martin called "Clean Code" and you'll see there is a lot a programmer can do to write good SOLID (yes that is a programming acronym) code that is easy to read, and easy to maintain with very few if any at all comments.

When I see a section of code that has more comments than code it smells funny.  Comments can lie about what that block of code is doing anyways.

If you keep the cyclomatic complexity down and follow the single responsibility principle, using well named methods and variables you just don't need comments since they are usually redundant.

Being novice has nothing to do with why a coder does or doesn't comment their code.  And uncommented code has very little proof that coder is a novice or not.  A novice usually writes a lot more code than is needed, it smells funny, has high cyclomatic complexity, lacks the use of design patterns, and is usually a nightmare to maintain. 

I didn't look at slic3r's code so I can't tell you if it's sloppy code or not, you're right that perl is a little vague in general which is why I'd never use it for a larger project that will grow and grow over time.

Ah! There's the software developer. I knew there was one on the forum. Good points! I think I may pick up the book you're suggesting - I don't have many on wider issues - most of my collection is on individual languages / philosophies. I wouldn't even say that Slic3r is sloppy - compared to some other slicing programs it looks organized from the outside.

Former Solidoodle employee, no longer associated with the company.

30 Reply by bahstrike

  • bahstrike
  • Member
  • Offline
  • Registered: 2012-09-27
  • Posts: 57

Re: Week 1 Solidoodle II Print Challenge (double helix)

I don't like where this is going-  these days there are more soap-boxes than software developers.
Given that this is a community and not a contest, I don't want to unleash a fight-  zimmer is right and made good points.

Frankly I'm more offended that solidoodlesupport said "There's the software developer" only after someone provides a glimpse into the world of Architectural Astronaut-ism.  It's as if I wrote my job title on a "Hi My Name Is" nametag with a crayon  (which is still OK-  neither of you are paying my salary).  So I will help clear up the Software Industry for you from a grittier, but equally realistic, perspective.

The software industry was born into this world pretty naively and pretty rapidly; a lot of mistakes have been made and as a result a lot of careers have been built solely around trying to coax people into doing things the best way.  The fact of the matter is, anyone intelligent enough to solve a complex software problem is almost certainly not going to be a complete dolt-  the project IS extensible otherwise the original author couldn't have finished it. Further nitpickings are just about as pompous as a vegetarian declaring that all meat-eaters are murderers  (which is questionably true, but unquestionably ridiculous).

If the code was hard to write, it should be hard to understand.






Quake II

extern unsigned blocklights[1024];    // allow some very large lightmaps

This is absolutely horrific..
- Arbitrary array size without a constant?
- Arbitrary array size on an extern??
- "Incomplete" type specifier?
- Global variable alert!
- No naming convention?

Yet..  I'm willing to bet better things have been derived from Carmack's work than Uncle Bob's.


JoelOnSoftware wrote:

It’s at this point you typically say, “Blistering Barnacles, we’ve got to get some consistent coding conventions around here!” and you spend the next day writing up coding conventions for your team and the next six days arguing about the One True Brace Style and the next three weeks rewriting old code to conform to the One True Brace Style until a manager catches you and screams at you for wasting time on something that can never make money, and you decide that it’s not really a bad thing to only reformat code when you revisit it, so you have about half of a True Brace Style and pretty soon you forget all about that and then you can start obsessing about something else irrelevant to making money like replacing one kind of string class with another kind of string class.

31 Reply by bahstrike

  • bahstrike
  • Member
  • Offline
  • Registered: 2012-09-27
  • Posts: 57

Re: Week 1 Solidoodle II Print Challenge (double helix)

Anyway John the droids you are looking for are here:
Slic3r / lib / Slic3r / Config.pm

'filament_diameter' => {
     label   => 'Diameter',
     tooltip => 'Enter your filament diameter here. Good precision is required, so use a caliper and do multiple measurements along the filament, then compute the average.',
     sidetext => 'mm',
     cli     => 'filament-diameter=f@',
     type    => 'f',
     serialize   => $serialize_comma,
     deserialize => $deserialize_comma,
     default     => [3],
},

32 Reply by solijohn

  • solijohn
  • Member
  • Offline
  • Registered: 2012-08-07
  • Posts: 1,465

Re: Week 1 Solidoodle II Print Challenge (double helix)

bahstrike wrote:

I don't like where this is going-  these days there are more soap-boxes than software developers.
Given that this is a community and not a contest, I don't want to unleash a fight-  zimmer is right and made good points.

Frankly I'm more offended that solidoodlesupport said "There's the software developer" only after someone provides a glimpse into the world of Architectural Astronaut-ism.  It's as if I wrote my job title on a "Hi My Name Is" nametag with a crayon  (which is still OK-  neither of you are paying my salary).  So I will help clear up the Software Industry for you from a grittier, but equally realistic, perspective.

The software industry was born into this world pretty naively and pretty rapidly; a lot of mistakes have been made and as a result a lot of careers have been built solely around trying to coax people into doing things the best way.  The fact of the matter is, anyone intelligent enough to solve a complex software problem is almost certainly not going to be a complete dolt-  the project IS extensible otherwise the original author couldn't have finished it. Further nitpickings are just about as pompous as a vegetarian declaring that all meat-eaters are murderers  (which is questionably true, but unquestionably ridiculous).

If the code was hard to write, it should be hard to understand.






Quake II

extern unsigned blocklights[1024];    // allow some very large lightmaps

This is absolutely horrific..
- Arbitrary array size without a constant?
- Arbitrary array size on an extern??
- "Incomplete" type specifier?
- Global variable alert!
- No naming convention?

Yet..  I'm willing to bet better things have been derived from Carmack's work than Uncle Bob's.


JoelOnSoftware wrote:

It’s at this point you typically say, “Blistering Barnacles, we’ve got to get some consistent coding conventions around here!” and you spend the next day writing up coding conventions for your team and the next six days arguing about the One True Brace Style and the next three weeks rewriting old code to conform to the One True Brace Style until a manager catches you and screams at you for wasting time on something that can never make money, and you decide that it’s not really a bad thing to only reformat code when you revisit it, so you have about half of a True Brace Style and pretty soon you forget all about that and then you can start obsessing about something else irrelevant to making money like replacing one kind of string class with another kind of string class.

No offense intended! John Carmack references appreciated. Also, great thanks for pointing me in the direction of that configuration bit. Should have found it ages ago.

Former Solidoodle employee, no longer associated with the company.