I just browsed around a bit, and noticed the following things:
(1) Put your code in a source folder. Having all your elm files in the same
folder as elm-package.json, .gitignore, index.html, etc is distracting. To
do this, add your source folder to the "source-directories" property in
elm-package.json, like this:
currently:
source-directories": [
"."
],
change it to:
"source-directories": [
"src"
],
(2) Auto-formatter? I don't like this one. It needlessly deeply indents
things, like the 'rotations'' function
here:
https://github.com/thomasballinger/loveinthetimeoftetris/blob/master/Piece.elm#L172
I prefer to put 'case ... of' on one line, the same line as the '=' it
follows, because it's usually short. Too much indentation makes code
unreadable. I think the official coding style (unfortunately) promotes this
though...
(3) 'rotate' looks very
inefficient:
https://github.com/thomasballinger/loveinthetimeoftetris/blob/master/Piece.elm#L172
It's just a bunch of 'if's. Why not turn 'Piece' into an enum type, and
then have 'rotate' pattern match the enum? ... The texture property looks
like it should just be a wrapper: 'type Textured a = Textured Int a'. ...
Using an 'Int' as an index for some list/array (I assume that's how it's
working.) is very C-like. Unless there's a nearly unlimited amount of
textures (one for each integer value), use an enumeration with a fixed
amount of constructors instead. To me, a type represents not only the shape
of its underlying data, *but also its **semantics** *. (I admit, Elm
doesn't fully embrace this philosophy yet, (partly because nearly all the
languages that have come before it don't either, so people still have
trouble thinking outside the C-like imperative-OO box), but I think it's
the way forward, because when it's paired with a strong type system like
Haskell's or Elm's, it prevents many logic errors, like adding 1 meter to 2
feet and getting 3 feet, or 4 ticks to 5 seconds and getting 9 seconds, or
7 apples to 8 oranges and getting 15 oranges, etc.)
(4) You should always give a function a type annotation:
https://github.com/thomasballinger/loveinthetimeoftetris/blob/master/Progression.elm#L23
.
>* I don't think I'll be using evancz/elm-graphics in the future since I'll
be doing less gamey stuff or want to work with canvas more directly. How is
this usually done?
By using Svg
instead: http://package.elm-lang.org/packages/elm-lang/svg/1.1.1
On Wednesday, August 17, 2016 at 4:40:38 PM UTC-5, Thomas Ballinger wrote:
>
> Hi Elm folks! I've enjoyed reading this list for a bit. I've written my
> first Elm thing over the last couple weeks and would love to hear any kind
> of feedback on it. It's an unfinished game jam piece I kept running with so
> the title doesn't make sense.
>
> code: https://github.com/thomasballinger/loveinthetimeoftetris
> live: love.ballingt.com (takes about 70 seconds to play all of)
>
> I was going to clean things up the way I know how, but I need to take a
> break to get some other things done and I thought I'd learn more by asking
> how someone else might clean it up. Please don't assume I know what I'm
> doing in the slightest :)
>
> Any feedback would be great, but if prompts are helpful:
> * what does this code make it look like I'm missing about Elm?
> * what do you think of the extensible record type aliases? I think the way
> I've used them is mostly terrible, I designed them up front instead of
> letting them evolve.
> * code style?
> * I'm using an elm autoformatter, how's my formatting? Is this style
> common?
> * I don't think I'll be using evancz/elm-graphics in the future since I'll
> be doing less gamey stuff or want to work with canvas more directly. How is
> this usually done?
> * I abandoned elm reactor once I started embedding in html, is that a
> viable workflow I should have stuck with for longer?
> * I was tempted to start a utils file or look for an external lib but was
> trying to focus on learning the stdlib. Are there pretty common util libs
> folks use? I sure missed some list functions.
> * I escaped to JavaScript anytime I thought it would be hard to do
> something with the stdlib, presumably it would be nice to use Elm for some
> of these things?
>
> Thanks so much, and feel free to contact off list if you prefer at
> m...@ballingt.com <javascript:> - if you do I'll report back what I
> learned to the list.
>
--
You received this message because you are subscribed to the Google Groups "Elm
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
