New Baseline #33
New Baseline #33
Conversation
Sonuva... Grrr.... Tabify screwed with commits. 1) Localize LeaderboardData to BuildLeaderboardAsync 2) Change return value of GetLeaderBoardDataAsync from Task to Task<LeaderboardData> 3) Inject data from BuildLeaderboardAsync into: BuildTopClassEmbed, BuildFirstTopAscendancyEmbed, BuildSecondTopAscendancyEmbed, BuildDiscordOnlyEmbed. 4) Fix URL scheme in GetLeaderBoardDataAsync
This reverts commit 7a73e29.
…rn"" This reverts commit 14e86ca.
In a situation where I need original database to compare to new tampered with database.
Luckily no keys were exposed.
Each function should do one thing. Pass the result to the next step
Move filtering from BuildRssFeedAsync to its own function
From excludeRecentPosts
Change forEach to list.
Move from BuikdRssFeedAsync
Marks completion of Task chain
Save database after all writes have completed.
Sending to Channels done separately
Move to outside of loop (only needs once per RSS feed.
Move code from BuildRssFeedAsync
Use a `List<object>` to transfer the built messages via DI to `SendToChannel()`
Allows higher functions to respond to errors appropriately.
Catching exceptions in the loop will avoid breaking the bot and allow only the broken builders/urls to continue on, while still providing debugging information
|
Generally, I prefer to know what subtype I'm dealing with before I know what it applies to. So id tells me what type of number it is, which is generally way more important for functionality than knowing where it goes. The "model" or "class" handles where it goes, but the subtype determines what I can do with it (if that makes sense) and what I must always keep in mind. It also allows me to group similar or related vars without having to read every varname... for example, idGuild and urlGuild and rssGuild are might be right next to each other. But in a guild only function, I'd only have to see the first few characters. For me, it's about reading and thought efficiency. |
|
@FuzzicalLogic personally I'm against Hungarian style, and while I understand what you're saying, would rather not have that if all possible. |
|
@Kyle-Undefined That's fair, and I'll fix it in the next PR. I would prefer to do it with the next PR because it will coincide well with the introduction of the STYLE_GUIDE.md. I hope that is alright. |
|
@FuzzicalLogic sounds good to me dude. I've just never been a fan of it, that's all. I'll hopefully be able to test tomorrow and merge. |
|
That's not a problem. I can work in a variety of styles. Unless it has a computational impact, I am very very flexible. If you see a style that I introduce without thought, definitely let me know. If you're interested as to why, please ask. And if you don't like it, please tell me. As a note: I don't code in hungarian notation primarily... just for subtypes. There's a distinct difference between noting a base type and a subtype. Base Types which can be easily determined in declaration and whose semantics can change according to environment or language. Subtypes like id are agnostic computationally, and are consistent across coding environments. |
|
Also, I'm going to open an Issue regarding Styles and Conventions, simply so we can lock those down in case others decide to contribute. That way we don't have to discuss it in the PRs or the discord. Also we can take time in case one of us feels strongly about an idea. Of course it will be closed as soon as the STYLE_GUIDE is complete. The reason is because there are many code types/patterns that I haven't seen in this example of code, so I want to have a forum for which to ask, discuss and get feedback for as they come up. |
Based on [PR 33](Kyle-Undefined#33)
|
@FuzzicalLogic yeah a style guide would be perfect. Personally I like method params to be camel case. But that's just me. We can flesh everything out and clean up what we come up with for the style guide as we go. |
Based on [PR 33](Kyle-Undefined#33)
**This PR need not be deployed. There are no functional benefits to this PR. **
While RssService changed considerably, the functionality is largely the same. This PR is mostly to provide a new base for implementing a branching strategy on my fork.