Finally a similar code structure!
Tags: opensource
Published: 2021-10-08 21:03:02

I have seen two other projects so far making an SSG. [One of them was in a different language](https://github.com/japneetsingh035/ModernSSG), so that explains how it would look different. [The other one](https://github.com/juuuuuuun/jun-ssg) - in the same language I used, JS - had a different structure and implementation. 

### Nice to read! ###
This time, however, my [third partner](https://github.com/JiaHua-Zou/Jia_SSG) had a similar structure to mine! I was glad to read that code, knowing I share the same ideas with someone. Makes me feel like I'm doing something right. On the other hand, we both could just be doing a same mistake. I don't really think there is a "mistaken" way to write code, but some are objectively worse in terms of readability and speed. To be exact, the similarity of our projects was in function structure. I generally encountered a [long big piece of code](https://github.com/japneetsingh035/ModernSSG/blob/main/Sources/ModernSSG/main.swift#L7) in one single function, or just a [couple functions](https://github.com/juuuuuuun/jun-ssg/blob/master/src/util/index.js#L104) before. In my project and my third partner's however - we had functions for specific tasks, which I think is the whole idea of functional programming. Now, perhaps I divided mine in too many small funcitons, which makes it worse to read. I'm not sure. I am sure that I liked my partner's code though!

## Implementing ##
At first I was lost in my task. I for sure read it wrong, since I have had a similar idea to implement way before this project - back in release 0.1. I wanted to change a default path for my input, since that was considered [bad practice](https://github.com/sirinoks/SSGNode/issues/16). But I still wanted to keep a default option, just for the sake of fast testing, instead of specifying a path every time. That's when the config idea came in. I tried to implement it back then, but I took on too many pieces - config, user input, async functions, error management... Yea, I got mostly stuck on user input which needed async stuff. I really struggle with async.

Now that I saw lab 3, I imagined I have to actually try again implementing all of those things. Turned out it wasn't the case. You didn't even need to generate a config through user input - it's literally a hand written JSON file. Yea.. turns out the task was actually easy...

The main problem I had with figuring out a solution was not understanding my partner's code. Yea, I know I said it was similar, however he used something I didn't - [yargs](https://github.com/JiaHua-Zou/Jia_SSG/blob/main/index.js#L4). Many people did. I thought I didn't need to use yarhs, but now as I'm having more and more arguments and it's getting hard to manage. I will add an [issue to transfer my own project to yargs](https://github.com/sirinoks/SSGNode/issues/31). Back to my partner's code - I had to figure out what each line meant and until I did I continued to have problems. It was one of those - *OOOOOHHHHH I WAS SO DUMB THAT MAKES SENSE*.

It was interesting to see how my partner chose their features to implement. I was so used to seeing a .css in other projects, I was surprised he didn't do it in his. 

### Actual code ###
As concrete details go.. I was happy to use my previous knowledge in making this PR work. The idea of [first making an object as a template](https://github.com/JiaHua-Zou/Jia_SSG/pull/20/commits/06a00a37701d55a85ea14dc0f83ca696446e4648#diff-ad4a5980d63aa762a2f34d0278456959ed0a2ff4c7cfb770df7ee7213a6a69d3R16-R19), only then [substituting data that you have](https://github.com/JiaHua-Zou/Jia_SSG/pull/20/commits/06a00a37701d55a85ea14dc0f83ca696446e4648#diff-ad4a5980d63aa762a2f34d0278456959ed0a2ff4c7cfb770df7ee7213a6a69d3R22-R25) to keep a logical structure is one I really liked. Simply put - it looks much better to write `clothes.hats, clothes.shirts` instead of `clothes[0], clothes[1]` or just `hats, shirts`. 

I have also learned something from my partner's pull request. He [checked for existing data](https://github.com/sirinoks/SSGNode/pull/30/commits/d900b307ff198275be7934b45f7b54bf1c20cbcc#diff-e727e4bdf3657fd1d798edcd6b099d6e092f8573cba266154583a746bba0f346R184) before assigning variables, which I haven't thought of by myself. Thanks to him I added those checks to [my code](https://github.com/JiaHua-Zou/Jia_SSG/pull/20/commits/06a00a37701d55a85ea14dc0f83ca696446e4648#diff-ad4a5980d63aa762a2f34d0278456959ed0a2ff4c7cfb770df7ee7213a6a69d3R40) as well, only with a better looking shortcut. I actually asked someone I know if I can write checks like `if (file)` and he said no :D. After I [googled](https://stackoverflow.com/questions/5515310/is-there-a-standard-function-to-check-for-null-undefined-or-blank-variables-in), turns out you can do that! It wasn't an argument really, but it was cool to find something a more experienced programmer didn't know.

### Reviewing his code ###
I honestly found this really easy and straightforward. Was it him doing a very good job, or our code structures being similar - he made it work and wrote it according to my style. I was impressed he figured out my [argument handling](https://github.com/sirinoks/SSGNode/pull/30/commits/d900b307ff198275be7934b45f7b54bf1c20cbcc#diff-e727e4bdf3657fd1d798edcd6b099d6e092f8573cba266154583a746bba0f346R234-R242). It looks kind of cancer tbh. That's why I want to [change it](https://github.com/sirinoks/SSGNode/issues/31)..

### Generally ###
I found this a good collab. We didn't have issues communicating, we did what we needed to do, learned things from each other, seems like everyone is happy. And I got [more work to do](https://github.com/sirinoks/SSGNode/issues?q=is%3Aopen+is%3Aissue+label%3ATODO)...